@techreport{hodson-hobs-00,
    number =    {draft-hodson-hobs-00},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-hodson-hobs/00/},
    author =    {Keith Richardson and Anthony Hodson and Erik Andersen and Louis Visser and Patrick Fantou and Jacqueline Pasquerau},
    title =     {{Hierarchical Operational Bindings - a profile}},
    pagetotal = 21,
    year =      1998,
    month =     feb,
    day =       25,
    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 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},
}