Hierarchical Operational Bindings - a profile

Document Type Expired Internet-Draft (individual)
Authors Keith Richardson  , Anthony Hodson  , Erik Andersen  , Louis Visser  , Patrick Fantou  , Jacqueline Pasquerau 
Last updated 1998-02-25
Stream (None)
Intended RFC status (None)
Expired & archived
plain text pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at


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 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 authentica


Keith Richardson (k.richardson@man05t1.wins.icl.co.uk)
Anthony Hodson (aeh@xdotd.demon.co.uk)
Erik Andersen (era@fl.dk)
Louis Visser (l.visser@nii.nl)
Patrick Fantou (Patrick.Fantou@mch.sni.de)
Jacqueline Pasquerau (jacqueline.pasquereau@edfgds.fr)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)