Internet DRAFT - draft-ietf-ldapext-hobs
draft-ietf-ldapext-hobs
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 04:43:31 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Mon, 23 Feb 1998 20:28:00 GMT
ETag: "2f5592-c12d-34f1dbd0"
Accept-Ranges: bytes
Content-Length: 49453
Connection: close
Content-Type: text/plain
INTERNET-DRAFT ISSS EGDIR
draft-ietf-ldapext-hobs-01.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-ietf-ldapext-hobs-01.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]