INTERNET-DRAFT ISSS EGDIR draft-hodson-hob-ady72-00.txt A Hodson (Editor) Expires in six months E Andersen (Chairman) L Visser P Fantou K Richardson J Pasquerau June 1997 Hierarchical Operational Bindings - a profile Filename: draft-hodson-hob-ady72-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 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 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. It was originated by EGDIR, the expert group within ISSS EGDIR [Page 1] INTERNET-DRAFT Hierarchical Operational Bindings - a profile June 1997 EWOS, the European Workshop for Open Systems, which is supported by some major players in X.500 design. This document was derived from a draft profile taken from the range of profiles intended as ISPs (Internationally Standardised profiles), developed jointly by the European, North American and Asiatic/Oceanic/Pacific workshops (EWOS, OIW and AOW). More information on '93 X.500 standard profiles is available from http://www.ewos.be and other sites. Contents 1. Introduction 2. Scenario 3. Definitions and abbreviations 3.1 Definitions 3.2 Abbreviations 4. Conformance - Hierarchical Operational Bindings 4.1 Static Conformance Requirements 4.2 Dynamic Conformance Requirements 5. Security considerations 6. Summary of support 7. References 8. Authors' Addresses 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 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 can only come into existence when the administrative authorities of each DSA permit it (e.g. by configuration of the DSA). It 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. ISSS EGDIR [Page 2] INTERNET-DRAFT Hierarchical Operational Bindings - a profile June 1997 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 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 ISSS EGDIR [Page 3] INTERNET-DRAFT Hierarchical Operational Bindings - a profile June 1997 * 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. HOB operations normally require the establishment of a DOP association within which each DSA will have authenticated itself to the other using simple authentication or better. The means of doing this is not within the scope of this document. However, the requirement to do so is profiled here. 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. ISSS EGDIR [Page 4] INTERNET-DRAFT Hierarchical Operational Bindings - a profile June 1997 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. +-----------------------------------+----+-----------+ | 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 | +-----------------------------------+----+-----------+ ISSS EGDIR [Page 5] INTERNET-DRAFT Hierarchical Operational Bindings - a profile June 1997 +-----------------------------------+----+-----------+ | 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 DAP Directory Access Protocol DIB Directory Information Base DIT Directory Information Tree DMD Directory Management Domain DSA Directory System Agent 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 POQ Partial outcome qualifier RDN Relative Distinguished Name RHOB Relevant hierarchical operation binding ROSE Remote Operations Service Element 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. ISSS EGDIR [Page 6] INTERNET-DRAFT Hierarchical Operational Bindings - a profile June 1997 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)). 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: ISSS EGDIR [Page 7] INTERNET-DRAFT Hierarchical Operational Bindings - a profile June 1997 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 may 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. 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. 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) ISSS EGDIR [Page 8] INTERNET-DRAFT Hierarchical Operational Bindings - a profile June 1997 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). 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 cannot 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 are recommended to do so. 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: ISSS EGDIR [Page 9] INTERNET-DRAFT Hierarchical Operational Bindings - a profile June 1997 * 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 is permitted to invoke a modify-operational-binding operation under other circumstances, even when no change has taken place, for example following a crash. 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. Credentials should normally be used. 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: ISSS EGDIR [Page 10] INTERNET-DRAFT Hierarchical Operational Bindings - a profile June 1997 * SuperiorToSubordinate.contextPrefixInfo * SuperiorToSubordinate.immediateSuperiorInfo * SubordinateToSuperior 4.1.8 Initiation by administrative intervention DSAs may optionally 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 are permitted to act always as if this were the validity used (see 4.2.2). 4.1.10 Termination A ROLE-A DSA may optionally 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 optionally be capable of invoking a termination operation for an active HOB when the naming context still exists. ISSS EGDIR [Page 11] INTERNET-DRAFT Hierarchical Operational Bindings - a profile June 1997 4.2 Dynamic Conformance Requirements To conform to 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 s 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 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) ISSS EGDIR [Page 12] INTERNET-DRAFT Hierarchical Operational Bindings - a profile June 1997 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). 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 is permitted to be configurable to not transmit this element 2. The DSA is permitted to 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 are recommended to use the default (element is absent), meaning valid from now until explicitly terminated. Responding DSAs are permitted to 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: ISSS EGDIR [Page 13] INTERNET-DRAFT Hierarchical Operational Bindings - a profile June 1997 * Access control (mandatory) * Subschema administration (optional but should be supported) * Collective attributes (optional but should be supported) within the requirements of: * DSA Simple Access Control or DSA 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 optionally be supported * entryInfo may optionally 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 ISSS EGDIR [Page 14] INTERNET-DRAFT Hierarchical Operational Bindings - a profile June 1997 regulate access to subordinate reference information. Disclosing the latter could give rise to a breach of security, and the entry ACI helps xontrol this. This entryACI may be passed back even if if SAC is to be used. 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). ISSS EGDIR [Page 15] INTERNET-DRAFT Hierarchical Operational Bindings - a profile June 1997 4.2.8 Errors Operational binding errors MUST be supported by ROLE-A and ROLE-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, adequate authentication is required, and DSAs need to be designed to accept HOBs only from suitably qualified sites. In addition, the initiation of a HOB is only tolerable when done by a qualified administrative user. The scenario for HOB creation and management is likely to be constrained mostly to a single organisation; this means that simpler forms of authentication may be adequate in the short term. 6. Summary of support The following clause summarises the functional and protocol support defined by this document. +----------------------------------------------------------+---+ | 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 ith 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 16] INTERNET-DRAFT Hierarchical Operational Bindings - a profile June 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 | +----------------------------------------------------------+---+ | Ditto - Subschema information | o | +----------------------------------------------------------+---+ | Ditto - 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 | m | +----------------------------------------------------------+---+ | Ditto using simple protected authentication | o | +----------------------------------------------------------+---+ | Ditto 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 | +----------------------------------------------------------+---+ | 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 | +----------------------------------------------------------+---+ ISSS EGDIR [Page 17] INTERNET-DRAFT Hierarchical Operational Bindings - a profile June 1997 +----------------------------------------------------------+---+ | Support by a ROLE-B DSA of a termination operation for | | | an active HOB when the naming context is removed | m | +----------------------------------------------------------+---+ | Ditto when the naming context still exists. | o | +----------------------------------------------------------+---+ | Support of simple-protected authentication with password | | | is mandatory ("none" authentication is considered | | | inappropriate for a management protocol) | m | +----------------------------------------------------------+---+ | For Supported Operational Binding types support of | | | specificHierarchicalBindingID is mandatory | m | +----------------------------------------------------------+---+ | The following DOP operations are mandatory | | | EstablishOperationalBinding | | | ModifyOperationalBinding | | | TerminateOperationalBinding, | m | | as used for hierarchical operational bindings | | +----------------------------------------------------------+---+ | In DirectoryBindArgument and DirectoryBindResult, as | | | used within DOP, the following must be supported | | | credentials | | | simple | | | name | | | password | | | as used for hierarchical operational bindings | m | +----------------------------------------------------------+---+ | In Establish Operational Binding Argument, the following | | | must be supported: | | | bindingID - the initiator must be able to place an Id | | | here | | | roleA-initiates (with SuperiorToSubordinate) | | | If roleB-initiates is supported, SubordinateToSuperior | | | must be supported. | m | +----------------------------------------------------------+---+ | In Establish Operational Binding Argument Result, the | | | following must be supported: | | | bindingID | | | initiator | m | +----------------------------------------------------------+---+ 7. References The following Directory standards are particularly relevant: [1] ISO/IEC 9594-2:1993 (X.501): Information Technology -- Open Systems Interconnection -- The Directory: Models. ISSS EGDIR [Page 18] INTERNET-DRAFT Hierarchical Operational Bindings - a profile June 1997 [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 EGDIR) XdotD Associates Spring Lanes House Holly Spring Lane Bracknell, Berkshire, ENGLAND Email: aeh@xdotd.demon.co.uk Erik Andersen (EGDIR Chairman) Fischer & Lorenz Tuborg Parkvej 10 DK2000 Hellerup, DENMARK Email: era@fl.dk ISSS EGDIR [Page 19] INTERNET-DRAFT Hierarchical Operational Bindings - a profile June 1997 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 20]