[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET-DRAFT                                              ISSS EGDIR
draft-hodson-hobs-00.txt                             A Hodson (Editor)
Expires in six months                            E Andersen (Chairman)
                                                              L Visser
                                                              P Fantou
                                                          K Richardson
                                                           J Pasquerau

                                                         December 1997


            Hierarchical Operational Bindings - a profile
              Filename: draft-hodson-hobs-00.txt


Status of this Memo

      This document is an Internet-Draft.  Internet-Drafts are working
      documents of the Internet Engineering Task Force (IETF), its
      areas, and its working groups.  Note that other groups may also
      distribute working documents as Internet-Drafts.

      Internet-Drafts are draft documents valid for a maximum of six
      months and may be updated, replaced, or obsoleted by other
      documents at any time.  It is inappropriate to use
      Internet-Drafts as reference material or to cite them other than
      as "work in progress."

      To view the entire list of current Internet-Drafts, please check
      the "1id-abstracts.txt" listing contained in the Internet-Drafts
      Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
      (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
      Coast), or ftp.isi.edu (US West Coast).

Abstract

      Where LDAP servers are based on X.500 DSAs for the holding of
      distributed Directory information, the maintenance of the
      necessary security and networking relationships between DSAs is
      an important factor to consider.

      The '93 X.500 Directory standards define HOB (Hierarchical
      Operational Binding) procedures for the creation of a new naming
      context in another DSA, and also for the maintenance of the
      relationship between two DSAs where one holds a superior naming
      context and the other holds a subordinate naming context.  The
      standards also define the use of the Directory Operational
      Binding Management Protocol (DOP) to mediate these procedures.

      The use of HOBs provides a major simplification for managers of
      X.500 systems, since it provides a way to update policies
      automatically from one DSA to another.  But practical design for
      HOBs requires decisions in a number of respects not fully


ISSS EGDIR                                                    [Page 1]


INTERNET-DRAFT Hierarchical Operational Bindings - a profile  Nov 1997


      treated by the standards.  This document simplifies the
      implementor's task by defining viable and practical subsets of
      the standards and by clarifying some of the issues left
      undefined by the standards.

      HOBs always represent an intimate relationship between DSAs
      which must be protected from masquerade. A method of providing
      this protection is given in the '93 Directory standards by
      requiring mutual authentication at the bind between DSAs. HOBS
      will normally only be established between DSAs owned by a single
      administrative authority, so security needs to be considered in
      this somewhat easier context than complete openness.

      Although simple unprotected authentication (name and password)
      can be a valid option in an already-secure environment, simple
      protected authentication using an encrypted password is
      potentially a much more secure technique, as is strong
      authentication using public key cryptography. All such
      techniques are validly used within the scope of this profile, as
      are techniques not defined but permitted by the Directory
      standards (these are known as ''external'' methods).

      Support of simple authentication is mandated for all
      implementations compliant with this profile.  Where this is not
      adequate, purchasers need to ensure that their requirements for
      are met.

Contents

      1.  Introduction                                               2
      2.  Scenario                                                   5
      3.  Definitions and abbreviations                              5
          3.1 Definitions                                            5
          3.2 Abbreviations                                          6
      4.  Conformance - Hierarchical Operational Bindings            7
          4.1 Static Conformance Requirements                        7
          4.2 Dynamic Conformance Requirements                      12
      5.  Security considerations                                   16
      6.  Summary of support                                        17
      7.  Transport Mappings                                        19
      8.  References                                                20
      9.  Authors' Addresses                                        20

1. Introduction

      This document provides guidelines for the implementation of
      Hierarchical Bindings (HOBs) by profiling the behaviour of a DSA
      in the context of HOBs.  It may also provides a basis for



ISSS EGDIR                                                    [Page 2]


INTERNET-DRAFT Hierarchical Operational Bindings - a profile  Nov 1997


      procurement of implementations that purport to offer HOB
      functionality.

      The HOB represents the relationship between two DSAs when one
      holds a superior naming context and the other contains (or is to
      contain) a subordinate naming context.

      A HOB MUST ONLY be permitted to come into existence when the
      administrative authorities of each DSA permit it (e.g.  by
      configuration of the DSA).  A HOB can be initiated in one of two
      ways:

      1.  By direct management action on the part of the
      administrative authority of one of the two DSAs.

      2. By the DSA that completes name resolution acting on an
      add-entry operation which specifies that an entry is to be
      placed in a DSA other than that holding its superior entry.

      In both cases, the HOB is initiated by an exchange of Directory
      Operational Management Binding Protocol (DOP) which establishes
      the Operational Binding.
      In the former case, the superior naming context and the
      subordinate reference to it from the superior DSA are presumed
      to pre-exist.  In the latter case, the exchange passes
      information about the contents of the new entry to the
      subordinate DSA, and form a part of a standardised procedure
      whereby (among other features):
      *   The subordinate DSA creates a new naming context by adding a
          context prefix entry with the required name and attribute
          information

      *   The superior DSA provides the DSA holding the subordinate
          naming context with all of the policy information (access
          control, subschema and collective attributes) required to
          administer the naming context

      *   The superior DSA creates a subordinate reference to the
          subordinate DSA with the required name

      HOB operations require the establishment of a DOP association
      within which each DSA will have authenticated itself to the
      other by an appropriate means of authentication.  Since DOP
      permits an intimate exchange between DSAs, authentication must
      be done adequately securely.  In some cases, the DOP exchanges
      are wholly within a secure environment and simple name/password
      authentication may suffice.  In other cases, authentication
      needs to be free from replay and other masquerade attacks.



ISSS EGDIR                                                    [Page 3]


INTERNET-DRAFT Hierarchical Operational Bindings - a profile  Nov 1997


      Simple protected authentication, in which the password is
      protected from replay by hashing with a time-stamp and random
      number may be adequate.  Strong authentication, using public key
      cryptography may also be appropriate if the necessary strong
      authentication infrastructure is in place.

      The actual process of authentication is not within the scope of
      this document.

      Once the HOB is established, it provides a means of
      automatically maintaining access point and policy information
      relevant to the naming context in the subordinate DSA and to the
      corresponding subordinate reference held in the superior DSA.

      A related process is described in the Standards whereby the
      reference from the superior to the subordinate DSA is a Non
      Specific Subordinate Reference.  This process is not within the
      scope of the present document.

      The objective of this document is to define capabilities and
      constraints on support for DSP by DSAs so that DSAs will be able
      to interwork using HOBs within the Directory.

      It therefore profiles the following:

      *   The configuration of DSAs in preparation for establishment
          of HOBs

      *   A superior DSA using a DOP establish-operational-binding
          operation to create a subordinate naming context in order to
          implement an add-entry operation in which the targetSystem
          element is present

      *   A subordinate DSA responding to a DOP
          establish-operational-binding operation

      *   Superior and subordinate DSAs as invokers and responders of
          DOP modify-operational-binding operations

      *   Superior and subordinate DSAs as invokers and responders of
          DOP terminate-operational-binding operations

      DSAs supporting HOBs are REQUIRED by the base standards to
      support DSP.







ISSS EGDIR                                                    [Page 4]


INTERNET-DRAFT Hierarchical Operational Bindings - a profile  Nov 1997


2. Scenario

      DSAs may be configured by their administrative authorities (by
      means outside the scope of the Directory standards) to allow
      them to create or accept Hierarchical Operational Bindings.

               Administrative                   Administrative
                 authority                        authority
                     \                                /
                       +--------+         +-----------+
                       |superior|         |subordinate|
      administr-       |  DSA   | DSA     |    DSA    |
      ative user       |   *    |         |     ^     |
      creating      DAP|  /*\   |   DOP   |    / \    |
      new naming  ====>| /***\  |<=======>|   /   \   |
      context    or DSP| ---^-  |         |   ---*-   |
      or maintain-     |   sub  |         |     /*\   |
      ing existing     |   ref  |         |    /***\  |
      one              +--------+         +-----------+

         Figure 1-DSA support of Hierarchical Operational Bindings

      A DSA configured in this way may then (after suitable stimulus)
      interact with another DSA using DOP operations.  This stimulus
      MAY be direct management action, or it MAY be DAP or DSP
      protocol action.  A particular stimulus is a request by an
      administrative user to establish a new naming context (triangle
      of asterisks at bottom of box for subordinate DSA).  Another MAY
      be an administrative authority action to coordinate two DSAs
      which already contain a superior and a subordinate naming
      context.
3. Definitions and abbreviations

3.1 Definitions

      Many of the definitions used may be found in the Directory
      Standards.  Since not all of the definitions are to be found in
      the Definitions clauses within the standards documents,
      references are listed in Table 1 below.  The "Part" reference
      refers to the part number within ISO/IEC 9594 or its ITU-T
      equivalent.










ISSS EGDIR                                                    [Page 5]


INTERNET-DRAFT Hierarchical Operational Bindings - a profile  Nov 1997


      +-----------------------------------+----+-----------+
      | Term                              |Part| Reference |
      +-----------------------------------+----+-----------+
      | administrative role               | 2  | 13.3      |
      | cooperative state                 | 2  | 22.1      |
      | Directory Operational Binding     |    |           |
      | Management Protocol (DOP)         | 2  | 11        |
      | directory operational framework   | 2  | 22.1      |
      | Hierarchical Operational Binding  |    |           |
      | (HOB)                             | 4  | 3         |
      | immediate superior reference      | 2  | 18.1      |
      | knowledge (information)           | 2  | 18.1      |
      | knowledge reference               | 2  | 18.1      |
      | master knowledge                  | 2  | 18.1      |
      | name resolution                   | 4  | 3         |
      | naming context                    | 4  | 17.1      |
      | non-cooperative state             | 2  | 22.1      |
      | Non-specific Hierarchical         |    |           |
      | Operational Binding (NHOB)        | 4  | 3         |
      | Non-specific Subordinate          |    |           |
      | Reference (NSSR)                  | 2  | 18.1      |
      | operational binding               | 2  | 22.1      |
      | operational binding establishment | 2  | 22.1      |
      | operational binding instance      | 2  | 22.1      |
      | operational binding management    | 2  | 22.1      |
      | operational binding modification  | 2  | 22.1      |
      | operational binding termination   | 2  | 22.1      |
      | operational binding type          | 2  | 22.1      |
      | relevant hierarchical operation   |    |           |
      | binding (RHOB)                    | 4  | 3         |
      | Simplified Access Control         | 2  | 16        |
      | subentry                          | 2  | 11.1      |
      | subordinate DSA                   | 4  | 3         |
      | subordinate reference             | 2  | 18.1      |
      | subrequest                        | 4  | 3         |
      | superior DSA                      | 4  | 3         |
      | target object name                | 4  | 3         |
      +-----------------------------------+----+-----------+
               Table 1: Definitions and references


3.2 Abbreviations

      The following abbreviations are used as defined in the Directory
      Standards or elsewhere:

      ACSE    Association Control Service Element
      APDU    Application Protocol Data Unit
      ASN.1   Abstract Syntax Notation One


ISSS EGDIR                                                    [Page 6]


INTERNET-DRAFT Hierarchical Operational Bindings - a profile  Nov 1997


      BAC     Basic Access Control
      DAP     Directory Access Protocol
      DIB     Directory Information Base
      DIT     Directory Information Tree
      DMD     Directory Management Domain
      DSA     Directory System Agent
      DOP     Directory Operational Binding Management Protocol
      DSE     DSA specific entry
      DSP     Directory System Protocol
      DUA     Directory User Agent
      EGDIR   Expert Group on the Directory
      EWOS    European Workshop for Open Systems
      HOB     Hierarchical operation binding
      IUT     Implementation under test
      NHOB    Non-specific hierarchical operation binding
      NSSR    Non-Specific Subordinate Reference
      PDU     Protocol Data Unit
      PICS    Protocol Implementation Conformance Statement
      POQ     Partial outcome qualifier
      RDN     Relative Distinguished Name
      RHOB    Relevant hierarchical operation binding
      ROSE    Remote Operations Service Element
      SAC     Simplified Access Control
      SPDU    Session Protocol Data Unit
      SSDU    Session Service Data Unit

4. Conformance - Hierarchical Operational Bindings

      This document specifies requirements upon DSA implementations to
      achieve interworking when using HOBs.  A claim of conformance to
      this document is a claim that all requirements in the relevant
      base standards are satisfied, and that all requirements in the
      following clauses are satisfied.

4.1 Static Conformance Requirements

      To conform to this document, DSA implementations MUST conform to
      all mandatory requirements of clause 9.2 in ISO/IEC 9594-5:1993
      (X.519), of Section 10 of ISO/IEC 9594-2:1993 (X.501), extended
      by mandatory requirements of Clause 24 of ISO/IEC 9594-4:1993
      (X.518), as applicable to a DSA implementing the
      directoryOperationalBindingManagementAC application context,
      including the requirements directly and indirectly referenced by
      that clause.

      NOTE.  A DSA claiming conformance to the
      directoryOperationalBindingManagementAC MUST also claim
      conformance to the directorySystemAC (see X.518 clause 9.2.1
      a)).


ISSS EGDIR                                                    [Page 7]


INTERNET-DRAFT Hierarchical Operational Bindings - a profile  Nov 1997


4.1.1 General capability

      DSAs conformant with this document MUST be capable of:

      1.  Acting in both ROLE-A (superior DSA) and ROLE-B (subordinate
          DSA), in accordance with X.518 clause 24.2, in order to
          implement the procedures associated with the targetSystem
          element of the DAP add-entry operation

      2.  When in ROLE-A (superior DSA), accepting an add-entry
          operation specifying targetSystem, and carrying out the
          procedures defined in X.518 clause 24.3 for the
          establishment of a HOB.

      DSAs SHOULD be capable of acting in ROLE-A (superior DSA), or
      ROLE-B (subordinate DSA), or both, in accordance with X.518
      clause 24.2, in order to implement a Hierarchical Operational
      Binding in respect of a pre-existing subordinate naming context
      which was established by local means.

      DSAs conformant with this document MUST be able to tolerate the
      case where they contain a superior or subordinate DSA, but no
      HOB exists.

4.1.2 HOB acceptability

      DSAs conformant with this document MUST be configurable to
      Reject HOBs under the following circumstances, in order to
      Permit administrative authorities sufficient control over
      Hierarchical bindings:

      1.  A ROLE-A DSA conformant with this document MUST be
          configurable to reject an add-entry operation specifying
          targetSystem in respect of any specific DSA.  In this case,
          it MUST either ignore the targetSystem element or respond to
          the invoker of the operation with a suitable error.  The
          latter capability is mandatory if target-system is specified
          as a critical extension.

      2.  A ROLE-A DSA conformant with this document MUST be
          configurable to reject an attempt to create a HOB when the
          proposed new naming context for the DSA has a name which is
          unacceptable when this is proposed by a ROLE-B DSA.  It MUST
          be possible for any specific name for an entry immediately
          subordinate to entries already held by the DSA to be
          configured as unacceptable in this sense, for the purposes
          of conformance testing.




ISSS EGDIR                                                    [Page 8]


INTERNET-DRAFT Hierarchical Operational Bindings - a profile  Nov 1997


      3.  A ROLE-B DSA conformant with this document MUST be
          configurable to reject a HOB when the naming context for the
          DSA has a name which is unacceptable when this is proposed
          by a ROLE-A DSA.  It MUST be possible for any entry name
          that is not superior or subordinate to entries already held
          by the DSA to be configured as unacceptable in this sense,
          for the purposes of conformance testing, possibly by
          implementing a list of names which are acceptable.

      4.  A ROLE-B DSA conformant with this document MUST be
          configurable to reject a HOB when this is proposed by any
          specific DSA attempting to act as a ROLE-A DSA.

      NOTE.  In some cases, there may be a requirement for human
      managers to interact (e.g. by telephone or Email) to accept or
      reject a request for a HOB.

4.1.3 HOB operations

      DSAs MUST support establishment, modification and termination
      operations in both ROLE-A and ROLE-B, within limitations defined
      in clause 4.2.

4.1.4 Information supported by HOBs

      ROLE-A DSAs conformant with this document MUST support the
      Supply and maintenance of all relevant administrative point and
      Subentry information for each vertex between the root and the
      Subordinate naming context (except when specified below as
      optional).  This includes:

      *   Access control information (both BAC and SAC)

      *   Subschema information (OPTIONALLY)

      *   Collective attribute information (OPTIONALLY)

      ROLE-A and ROLE-B DSAs MUST support the supply and maintenance
      Of their own access points.

      ROLE-A DSAs are NOT REQUIRED to support the modification of a
      HOB which would change the DN of the context prefix for the
      subordinate naming context except that ROLE-A DSAs are REQUIRED
      to support a change in RDN of the subordinate context prefix
      (while retaining the DN of the superior entry).





ISSS EGDIR                                                    [Page 9]


INTERNET-DRAFT Hierarchical Operational Bindings - a profile  Nov 1997


      ROLE-A DSAs are NOT REQUIRED to support the modification of a
      HOB which would change the DN of the context prefix for the
      Superior naming context without changing the DN of the context
      prefix for the subordinate naming context (i.e.  moving the
      context prefix for the subordinate naming context up or down the
      DIT).

      ROLE-B DSAs are NOT REQUIRED to supply and maintain entry
      information for the context prefix in the superior DSA (i.e.  as
      entryInfo in the SubordinateToSuperior establishment parameter -
      see X.518 clause 24.4.1.2).  If not supplied, the superior DSA
      does not have the information necessary to make access control
      decisions that take into account policies within the subordinate
      DSA; it MAY be able to implement locally defined policies
      instead.  However, they SHOULD supply the entry information.

      NOTE.  If however they do so supply it, they MUST be capable of
      maintaining it (see 4.1.5).

4.1.5 Established Hierarchical Bindings

      After a hierarchical operational binding has been successfully
      established, the following requirements are placed on ROLE-A and
      ROLE-B DSAs:

      1.  ROLE-A DSAs MUST be capable of establishing a DOP
          association, and using it to invoke a
          modify-operational-binding operation consequent upon the
          following stimuli:

          *   Any change in contextPrefixInfo as it would be
              transmitted in modify-operational-binding argument

          *   Any change in the access point of the DSA

      2.  ROLE-B DSAs MUST similarly be capable of establishing a DOP
          association, and using it to invoke a
          modify-operational-binding operation consequent upon the
          following stimuli:

          *   Any change in entryInfo within the scope of interest to
              the ROLE-A DSA, to include object class and entryACI
              (when present)

          *   Any change in the access point of the DSA

      Either role MAY invoke a modify-operational-binding
      operation under other circumstances, even when no change has
      taken place, for example following a crash.


ISSS EGDIR                                                   [Page 10]


INTERNET-DRAFT Hierarchical Operational Bindings - a profile  Nov 1997


4.1.6 Security Level

      Implementations MUST be able to carry out the peer entity
      authentication of DSAs by the following ways:

      *   Simple authentication with unprotected password

      The following methods of peer entity authentication are OPTIONAL
      (see Note 2 below):

      *   Simple protected authentication

      *   Strong authentication

      DSAs conformant with this document MUST be capable of rejecting
      DOP binds that use no authentication, or that use simple
      unprotected authentication without password.

      Notes

      1.  Since HOBs establish trusted relationships between DSAs,
          authentication MUST be adequately secure.  Secure means of
          authentication that counter observation and replay attacks,
          such as simple protected authentication or strong
          authentication using public key cryptography should be
          considered.

      2.  The use of external authentication using the
          externalProcedure element in accordance with ISO/IEC
          9594-4:1993 (X.518) clause 11.1 and ISO/IEC 9594-3:1993
          (X.511) clause 8.1.2 is outside the scope of this document.

4.1.7 Disclosure of HOB information

      DSAs acting in ROLE-A or ROLE-B MUST be configurable to refuse
      direct DAP or DSP access to any information received as a result
      of the HOB, other than entryInfo by a ROLE-B DSA.

      NOTE.  This requirement states that the following information is
      regarded as internal, although access to it MAY be required for
      system management or diagnostic purposes, even when it can in
      principle be formulated to provide attribute information:

      *   SuperiorToSubordinate.contextPrefixInfo

      *   SuperiorToSubordinate.immediateSuperiorInfo

      *   SubordinateToSuperior



ISSS EGDIR                                                   [Page 11]


INTERNET-DRAFT Hierarchical Operational Bindings - a profile  Nov 1997


4.1.8 Initiation by administrative intervention

      DSAs MAY support the initiation of a HOB in respect of
      a pre-existing naming context.  If supported, initiation MUST be
      possible by either the ROLE-A or the ROLE-B DSA creating a DOP
      association and invoking an establish-operational-binding
      operation conformant with HOB requirements.

      Following successful establishment, each DSA conformant to this
      document MUST support modify-operational-binding operations as
      in clause 4.1.4.

4.1.9 Validity

      Since a HOB represents the existence of bothe a superior and a
      subordinate naming context, DSAs in ROLE-A and ROLE-B are NOT
      REQUIRED to support validity other than the default validity for
      the operational binding:

      *   Valid from now ...

      *   Until explicitly terminated

      ROLE-A and ROLE-B DSAs MAY act always as if this
      were the validity used (see 4.2.2).

4.1.10 Termination

      A ROLE-A DSA MAY be capable of invoking a termination
      operation for an active HOB.  This can only occur as a
      consequence of Administrative Authority action.

      A ROLE-B DSA MUST be capable of invoking a termination operation
      for an active HOB when the naming context is removed (e.g.  by a
      remove-entry operation for the context prefix).

A ROLE-B DSA MAY be capable of invoking a termination
      operation for an active HOB when the naming context still
      exists.

4.2 Dynamic Conformance Requirements

      To conform to this document, implementations MUST conform to all
      mandatory requirements of 9.2.3 and 7.5 in ISO/IEC 9594-5:1993
      (X.519) for a DSA supporting the
      directoryOperationalBindingManagementAC application context.
      Implementations MUST conform to all procedures specified in the
      directory base standards relating to Hierarchical Operational
      Bindings, as amended by the corrigenda listed in clause 7 of


ISSS EGDIR                                                   [Page 12]


INTERNET-DRAFT Hierarchical Operational Bindings - a profile  Nov 1997


      this document, as they relate to operations and protocol
      elements for which support is claimed in the PICS.  Attention is
      drawn to the following clauses of ISO/IEC 9594-4:1993 (X.518):

      *   Add-entry operations affecting HOBs (clause 19.1.1) ,
          including those that add relevant subentries

      *   Remove-entry operations affecting HOBs (clause 19.1.2),
          including those that remove relevant subentries

      *   Modify-entry operations affecting HOBs (clause 19.1.3),
          including those that remove relevant subentries

      *   Modify-DN operations affecting HOBs (clause 19.1.4),
          including those that change the names of relevant subentries

      There are limitations on the support for modify-DN operations
      (see 4.1.4).

4.2.1 ROLE-A Support - Establishment Parameters

4.2.1.1 Vertex

      In the case of administrative points, the following information
      MUST be supplied in contextPrefixInfo for each vertex:

      *   In admPointInfo, the administrative role attribute if
          relevant (i.e.  there is no ppp-specific point interposed
          between the vertex and the new entry where ppp is any of the
          three administrative purposes: access-control, subschema
          administration, collective attributes)

      *   In admPointInfo, the access-control-scheme attribute if
          relevant (i.e.  there is no access control specific point
          interposed between the vertex and the new entry)

      *   In subentryInfo, the complete information in all relevant
          subentries (i.e.  subentries for each administrative purpose
          ppp where there is no ppp-specific point interposed between
          the vertex and the new entry)

      The accessPoints element MUST be present when the vertex
      corresponds to the context prefix of the superior naming context
      which is the subject of the HOB.  However a ROLE-A DSA is
      permitted to pass either an empty SET OF as
      MasterAndShadowAccessPoints or a SET OF that contains only the
      master access-point (i.e.  a reference to itself).




ISSS EGDIR                                                   [Page 13]


INTERNET-DRAFT Hierarchical Operational Bindings - a profile  Nov 1997


      If shadow access points are present in
      MasterAndShadowAccessPoints, the master access-point MUST also
      be present.

4.2.1.2 Entry information

      When the HOB is initiated as a result of an add-entry operation,
      the DSA MUST supply in SET OF Attribute the exact information
      supplied by SET OF Attribute within the add-entry operation.

4.2.1.3 Immediate superior info

      The ImmediateSuperiorInfo element MUST be supported, and MUST
      contain the objectClass and entryACI attributes.

      NOTES

      1.  The DSA MAY be configurable to not transmit this
          element

      2.  The DSA MAY supply other attributes

4.2.2 Validity

      Since a HOB of this kind represents a de-facto situation (i.e.
      the presence or otherwise of a subordinate naming context), the
      components of Validity are not relevant to practical operations.

      Initiating DSAs SHOULD use the default (element is
      absent), meaning valid from now until explicitly terminated.

      Responding DSAs MAY ignore the element (i.e.  treat
      it as if the default had been received).

4.2.3 ROLE-B Support - Establishment Parameters

      DSAs acting in ROLE-B MUST be capable of supporting:

      1.  Administrative information supplied in contextPrefixInfo, in
          respect of some or all of the administrative purposes:

          *   Access control (MANDATORY)

          *   Subschema administration (SHOULD be
              supported)

          *   Collective attributes (SHOULD be supported)

          in accordance with the REQUIREMENTS of the Standards for:


ISSS EGDIR                                                   [Page 14]


INTERNET-DRAFT Hierarchical Operational Bindings - a profile  Nov 1997


          *   Simplified Access Control or Basic Access Control

          *   Administrative Areas

          *   Schema Administration

      2.  Knowledge information for an immediate-superior reference
          supplied in accessPoints within contextPrefixInfo.

      A DSA is NOT REQUIRED to implement the optimisation of the list
      operation supported by ImmediateSuperiorInfo (X.518 clause
      19.3.1.2.1 3 a), 24.1.4.2 Note).

      A DSA MUST support the subordinateToSuperior value as follows:

      *   accessPoints MUST be supported, except that only support for
          a master reference is REQUIRED (Shadow references wouldn't
          be available at this stage, but they could be present for
          the use in MODIFICATION-PARAMETERS).

      *   alias MAY be supported

      *   entryInfo MAY be supported

      When entryInfo is supported, it MUST comprise at least:

      *   The objectClass attribute

      *   An entryACI attribute, synthesised as necessary to contain
          all the ACI that is relevant to the access of the context
          prefix.

      The last of these is used to indicate all of the ACI relevant to
      the entry which is derived from the context prefix's entry ACI
      (if any) together with any precriptive ACI derived from the
      context prefix's subentries (if any) and relevant to the context
      prefix.  The ACI values are simply gathered together to form a
      synthesised attribute.  This information can be supplied to
      optimise the handling of access control for lists, and also to

      regulate access to subordinate reference information.
      Disclosing the latter could give rise to a breach of security,
      and the entry ACI helps control this for the purposes of DAP or
      DSP operations (which are outside the present scope).

      This entryACI MAY be passed back even if SAC is to be used.





ISSS EGDIR                                                   [Page 15]


INTERNET-DRAFT Hierarchical Operational Bindings - a profile  Nov 1997


4.2.4 Modification Parameters

4.2.4.1 ROLE-A Parameters

      Support MUST be as for establishment parameters, except that
      entryInfo is absent in SuperiorToSubordinateModification (it is
      otherwise identical to SuperiorToSubordinate).

4.2.4.2 ROLE-B Parameters

      Support MUST be as for establishment parameters.

4.2.5 Termination

      A ROLE-B DSA in receipt of a termination invoke from a ROLE-A
      DSA MUST be capable of accepting the termination.  However,
      there is no requirement to remove the subordinate naming
      context, or to change any of the administrative policies that
      pre-existed before the termination.

      A ROLE-B DSA MUST be capable of invoking a termination operation
      for an active HOB when the naming context is removed (e.g.  by a
      remove-entry operation for the context prefix).

      A ROLE-A DSA from a ROLE-A DSA in receipt of a termination
      invoke MUST be capable of accepting the termination.

4.2.6 Rules of Extensibility for Result and Error Handling

      Implementations MUST satisfy the rule of extensibility for
      Result and error handling specified in clause 7.5 of ISO/IEC
      9594-5:1993 (X.519).

4.2.7 Digital Signatures

      Digital signatures are not supported by 1993 DOP operations
      (although this anomaly is rectified by the 1997 Directory
      standards).

4.2.8 Errors

      Operational binding errors MUST be supported by ROLE-A and OLE-B
      DSAs in conformance with X.501 clause 24.5.


5. Security considerations

      HOBs permit an intimate relationship to exist between two DSAs;
      the feature needs to be carefully protected.  For this reason,


ISSS EGDIR                                                   [Page 16]


INTERNET-DRAFT Hierarchical Operational Bindings - a profile  Nov 1997


      adequate authentication is REQUIRED, and DSAs need to be
      designed to accept HOBs ONLY from suitably qualified sites. (See
      the statements on authentication requirements in the
      Introduction.) In addition, the initiation of a HOB is ONLY
      tolerable when done by a qualified administrative user.
      Protection from other users MAY be provided by Access Control or
      other means.

      By "adequate authentication" is meant "a means of authentication
      which satisfies the requirements of the local Security Policy on
      masquerade and related threats".

      By "qualified administrative user" is meant a human party to
      whom authority has been given by the owning organisation to
      operate the DSA (or DSAs) involved, and for whom a suitable
      means of authentication has been provided".

6. Summary of support

      The following clause summarises the functional and protocol
      support defined by this document.  In the second column, the
      letter "m" indicates that the requirement is MANDATORY.  The
      letter "o" indicates that the requirement is OPTIONAL.

      +----------------------------------------------------------+---+
      | Support of both ROLE-A and ROLE-B in implementing        |   |
      | the targetSystem element and procedure of add-entry      |   |
      | to create a HOB                                          | m |
      +----------------------------------------------------------+---+
      | Support of ROLE-A or ROLE-B in implement a HOB in respect|   |
      | of a pre-existing subordinate naming context which was   |   |
      | established by local means.                              | m |
      +----------------------------------------------------------+---+
      | For a ROLE-A DSA, support of configuration to reject an  |   |
      | add-entry operation specifying targetSystem in respect of|   |
      | any specific DSA.                                        | m |
      +----------------------------------------------------------+---+
      | DSAs conformant with this document MUST be able to       |   |
      | tolerate the case where they contain a superior or       |   |
      | subordinate DSA, but no HOB exists.                      | m |
      +----------------------------------------------------------+---+
      | For a ROLE-A DSA, support of configuration to reject an  |   |
      | attempt to create a HOB when the ROLE-B DSA proposes a   |   |
      | new naming context with an unacceptable name             | m |
      +----------------------------------------------------------+---+
      | For a ROLE-B DSA, support of configuration to reject an  |   |
      | attempt to create a HOB proposed by a ROLE-A DSA for a   |   |
      | new naming context with a name unacceptable to it        | m |
      +----------------------------------------------------------+---+


ISSS EGDIR                                                   [Page 17]


INTERNET-DRAFT Hierarchical Operational Bindings - a profile  Nov 1997


      +----------------------------------------------------------+---+
      | For a ROLE-B DSA, support of configuration to reject a   |   |
      | HOB proposed by any specific ROLE-A DSA                  | m |
      +----------------------------------------------------------+---+
      | Support of establishment, modification, and termination  |   |
      | operations in ROLE-A and ROLE-B, subject to clause 4.2   | m |
      +----------------------------------------------------------+---+
      | Support of transfer of administrative point and subentry |   |
      | information by ROLE-A DSAs: Access control information   | m |
      +----------------------------------------------------------+---+
      | Support of transfer of administrative point and subentry |   |
      | information by ROLE-A DSAs: Subschema information        | o |
      +----------------------------------------------------------+---+
      | Support of transfer of administrative point and subentry |   |
      | information by ROLE-A DSAs: Collective attribute         |   |
      | information                                              | o |
      +----------------------------------------------------------+---+
      | Support, by both ROLE-A and ROLE-B DSAs of the supply and|   |
      | maintenance of their own access points.                  | m |
      +----------------------------------------------------------+---+
      | Support by ROLE-A of a change in RDN of the subordinate  |   |
      | context prefix (retaining the DN of the superior entry)  | m |
      +----------------------------------------------------------+---+
      | Support by ROLE-A DSAs of establishing a DOP association,|   |
      | to invoke a modify-operational-binding operation after   |   |
      |   Any change in contextPrefixInfo                        |   |
      |   Any change in the access point of the DSA              | m |
      +----------------------------------------------------------+---+
      | Support by ROLE-B DSAs of establishing a DOP association |   |
      | to invoke a modify-operational-binding operation after   |   |
      |   Any change in entryInfo as previously supplied         |   |
      |   Any change in the access point of the DSA              | m |
      +----------------------------------------------------------+---+
      | Support of DOP binds using simple authentication with    |   |
      | unprotected password (this may be inadequate for some    |   |
      | purposes, but is mandated as a minimal capability)       | m |
      +----------------------------------------------------------+---+
      | Support of DOP binds using simple protected              |   |
      | authentication                                           | o |
      +----------------------------------------------------------+---+
      | Support of DOP binds using strong authentication         | o |
      +----------------------------------------------------------+---+
      | Capable of rejecting DOP binds that use no               |   |
      | authentication, or that use simple unprotected           |   |
      | authentication without password.                         | m |
      +----------------------------------------------------------+---+
      | Support of configuration as ROLE-A or ROLE-B to refuse   |   |
      | direct DAP or DSP access to information received using   |   |
      | other than entryInfo supplied by a ROLE-B DSA.           | m |
      +----------------------------------------------------------+---+

ISSS EGDIR                                                   [Page 18]


INTERNET-DRAFT Hierarchical Operational Bindings - a profile  Nov 1997


      +----------------------------------------------------------+---+
      | Support by a ROLE-A or ROLE-B DSA of creation of a HOB   |   |
      | in respect of a pre-existing naming context, and         |   |
      | subsequent support of modify-operational-binding         |   |
      | operations                                               | m |
      +----------------------------------------------------------+---+
      | Support by a ROLE-B DSA of a termination operation for   |   |
      | an active HOB when the naming context is removed         | m |
      +----------------------------------------------------------+---+
      | Support by a ROLE-B DSA of a termination operation for   |   |
      | an active HOB when the naming context still exists.      | o |
      +----------------------------------------------------------+---+
      | Support of specificHierarchicalBindingID                 | m |
      +----------------------------------------------------------+---+
      | Support of the following DOP operations:                 |   |
      |    EstablishOperationalBinding                           |   |
      |    ModifyOperationalBinding                              |   |
      |    TerminateOperationalBinding,                          | m |
      | as used for hierarchical operational bindings            |   |
      +----------------------------------------------------------+---+
      | Support of the following in In DirectoryBindArgument and |   |
      | DirectoryBindResult, as used within DOP:                 |   |
      |    credentials                                           |   |
      |    simple                                                |   |
      |    name                                                  |   |
      |    password                                              |   |
      | as used for hierarchical operational bindings            | m |
      +----------------------------------------------------------+---+
      | Support of the following in Establish Operational        |   |
      | Binding:                                                 |   |
      |    bindingID - the initiator MUST be able to place an Id |   |
      |        here                                              |   |
      |    roleA-initiates (with SuperiorToSubordinate)          | m |
      +----------------------------------------------------------+---+
      | If roleB-initiates is supported, support of              |   |
      | SubordinateToSuperior                                    | m |
      +----------------------------------------------------------+---+
      | In Establish Operational Binding Argument Result, support|   |
      | of the following:                                        |   |
      |    bindingID                                             |   |
      |    initiator                                             | m |
      +----------------------------------------------------------+---+

7. Transport Mappings

      Requirements on transport mappings are outside the scope of this
      document.




ISSS EGDIR                                                   [Page 19]


INTERNET-DRAFT Hierarchical Operational Bindings - a profile  Nov 1997


8. References

      The following Directory standards are particularly relevant:

      [1] ISO/IEC 9594-2:1993 (X.501): Information Technology -- Open
      Systems Interconnection -- The Directory: Models.

      [2] ISO/IEC 9594-3:1993 (X.511): Information Technology -- Open
      Systems Interconnection -- The Directory: Abstract Service
      Definition.

      [3] ISO/IEC 9594-4:1993 (X.518): Information Technology -- Open
      Systems Interconnection -- The Directory: Procedures for
      Distributed Operations.

      [4] ISO/IEC 9594-5:1993 (X.519): Information Technology -- Open
      Systems Interconnection -- The Directory: Protocol
      Specifications.

      The amendments and corrigenda as listed below are considered as
      normative references by this document.

      +----+-----------------------------+---------------------------+
      | 1  | ISO/IEC 9594-2:1993 (X.501) | Cor.1: 1995               |
      | 2  | ISO/IEC 9594-2:1993 (X.501) | Draft Cor.2: 1995         |
      | 3  | ISO/IEC 9594-8:1993 (X.509) | Cor.1: 1995               |
      | 4  | ISO/IEC 9594-8:1993 (X.509) | Cor.2: 1995               |
      | 5  | ISO/IEC 9594-8:1993 (X.509) | Draft Cor.3: 1995         |
      | 6  | ISO/IEC 9594-3:1993 (X.511) | Cor.1: 1995               |
      | 7  | ISO/IEC 9594-3:1993 (X.511) | Draft Cor.2: 1995         |
      | 8  | ISO/IEC 9594-4:1993 (X.518) | Cor.1: 1995               |
      | 9  | ISO/IEC 9594-4:1993 (X.518) | Draft Cor.2: 1995         |
      | 10 | ISO/IEC 9594-5:1993 (X.519) | Cor.1: 1995               |
      | 11 | ISO/IEC 9594-6:1993 (X.520) | Cor.1: 1995               |
      | 12 | ISO/IEC 9594-9:1993 (X.525) | Cor.1: 1995               |
      | 13 | ISO/IEC 9594-9:1993 (X.525) | Draft Cor.2: 1995         |
      +----+-----------------------------+---------------------------+

8. Authors' Addresses

      Anthony Hodson (Editor for ISSS EGDIR)
      XdotD Associates
      Spring Lanes House
      Holly Spring Lane
      Bracknell, Berkshire, ENGLAND
      Email: aeh@xdotd.demon.co.uk





ISSS EGDIR                                                   [Page 20]


INTERNET-DRAFT Hierarchical Operational Bindings - a profile  Nov 1997


      Erik Andersen (ISSS EGDIR Chairman)
      Fischer & Lorenz
      Tuborg Parkvej 10
      DK2000 Hellerup, DENMARK
      Email: era@fl.dk

      Keith Richardson
      ICL
      High Performance Systems
      Wenlock Way, West Gorton
      Manchester M12 5DR  ENGLAND
      Email: k.richardson@man0523.wins.icl.co.uk

      Louis Visser
      Netherlands Normalisatie-instituut
      Kalfjeslaan 2
      Delft, NETHERLANDS,
      Email: l.visser@nni.nl

      Patrick Fantou
      Siemens Nixdorf Informationssysteme AG
      ASW BA COM2
      Otto-Hahn-Ring 6
      D-81739 MUNICH GERMANY
      Email: Patrick.Fantou@mch.sni.de

      Jacqueline Pasquerau
      EDFGDS
      STI
      21 Rue Joseph Bara
      92132 Issy les Moulineaux CEDEX
      FRANCE
      Email: jacqueline.pasquereau@edfgds.fr


















ISSS EGDIR                                                   [Page 21]