Internet DRAFT - draft-hodson-hob-ady72
draft-hodson-hob-ady72
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]
