idnits 2.17.1 draft-hodson-hobs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 107: '... A HOB MUST ONLY be permitted to ...' RFC 2119 keyword, line 191: '...porting HOBs are REQUIRED by the base ...' RFC 2119 keyword, line 218: '... MAY be direct management action,...' RFC 2119 keyword, line 221: '...box for subordinate DSA). Another MAY...' RFC 2119 keyword, line 320: '...t, DSA implementations MUST conform to...' (71 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 209 has weird spacing: '...context or ...' -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 1997) is 9628 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 920, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 923, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 927, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 931, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT ISSS EGDIR 2 draft-hodson-hobs-00.txt A Hodson (Editor) 3 Expires in six months E Andersen (Chairman) 4 L Visser 5 P Fantou 6 K Richardson 7 J Pasquerau 9 December 1997 11 Hierarchical Operational Bindings - a profile 12 Filename: draft-hodson-hobs-00.txt 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use 24 Internet-Drafts as reference material or to cite them other than 25 as "work in progress." 27 To view the entire list of current Internet-Drafts, please check 28 the "1id-abstracts.txt" listing contained in the Internet-Drafts 29 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 30 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 31 Coast), or ftp.isi.edu (US West Coast). 33 Abstract 35 Where LDAP servers are based on X.500 DSAs for the holding of 36 distributed Directory information, the maintenance of the 37 necessary security and networking relationships between DSAs is 38 an important factor to consider. 40 The '93 X.500 Directory standards define HOB (Hierarchical 41 Operational Binding) procedures for the creation of a new naming 42 context in another DSA, and also for the maintenance of the 43 relationship between two DSAs where one holds a superior naming 44 context and the other holds a subordinate naming context. The 45 standards also define the use of the Directory Operational 46 Binding Management Protocol (DOP) to mediate these procedures. 48 The use of HOBs provides a major simplification for managers of 49 X.500 systems, since it provides a way to update policies 50 automatically from one DSA to another. But practical design for 51 HOBs requires decisions in a number of respects not fully 52 treated by the standards. This document simplifies the 53 implementor's task by defining viable and practical subsets of 54 the standards and by clarifying some of the issues left 55 undefined by the standards. 57 HOBs always represent an intimate relationship between DSAs 58 which must be protected from masquerade. A method of providing 59 this protection is given in the '93 Directory standards by 60 requiring mutual authentication at the bind between DSAs. HOBS 61 will normally only be established between DSAs owned by a single 62 administrative authority, so security needs to be considered in 63 this somewhat easier context than complete openness. 65 Although simple unprotected authentication (name and password) 66 can be a valid option in an already-secure environment, simple 67 protected authentication using an encrypted password is 68 potentially a much more secure technique, as is strong 69 authentication using public key cryptography. All such 70 techniques are validly used within the scope of this profile, as 71 are techniques not defined but permitted by the Directory 72 standards (these are known as ''external'' methods). 74 Support of simple authentication is mandated for all 75 implementations compliant with this profile. Where this is not 76 adequate, purchasers need to ensure that their requirements for 77 are met. 79 Contents 81 1. Introduction 2 82 2. Scenario 5 83 3. Definitions and abbreviations 5 84 3.1 Definitions 5 85 3.2 Abbreviations 6 86 4. Conformance - Hierarchical Operational Bindings 7 87 4.1 Static Conformance Requirements 7 88 4.2 Dynamic Conformance Requirements 12 89 5. Security considerations 16 90 6. Summary of support 17 91 7. Transport Mappings 19 92 8. References 20 93 9. Authors' Addresses 20 95 1. Introduction 97 This document provides guidelines for the implementation of 98 Hierarchical Bindings (HOBs) by profiling the behaviour of a DSA 99 in the context of HOBs. It may also provides a basis for 100 procurement of implementations that purport to offer HOB 101 functionality. 103 The HOB represents the relationship between two DSAs when one 104 holds a superior naming context and the other contains (or is to 105 contain) a subordinate naming context. 107 A HOB MUST ONLY be permitted to come into existence when the 108 administrative authorities of each DSA permit it (e.g. by 109 configuration of the DSA). A HOB can be initiated in one of two 110 ways: 112 1. By direct management action on the part of the 113 administrative authority of one of the two DSAs. 115 2. By the DSA that completes name resolution acting on an 116 add-entry operation which specifies that an entry is to be 117 placed in a DSA other than that holding its superior entry. 119 In both cases, the HOB is initiated by an exchange of Directory 120 Operational Management Binding Protocol (DOP) which establishes 121 the Operational Binding. 122 In the former case, the superior naming context and the 123 subordinate reference to it from the superior DSA are presumed 124 to pre-exist. In the latter case, the exchange passes 125 information about the contents of the new entry to the 126 subordinate DSA, and form a part of a standardised procedure 127 whereby (among other features): 128 * The subordinate DSA creates a new naming context by adding a 129 context prefix entry with the required name and attribute 130 information 132 * The superior DSA provides the DSA holding the subordinate 133 naming context with all of the policy information (access 134 control, subschema and collective attributes) required to 135 administer the naming context 137 * The superior DSA creates a subordinate reference to the 138 subordinate DSA with the required name 140 HOB operations require the establishment of a DOP association 141 within which each DSA will have authenticated itself to the 142 other by an appropriate means of authentication. Since DOP 143 permits an intimate exchange between DSAs, authentication must 144 be done adequately securely. In some cases, the DOP exchanges 145 are wholly within a secure environment and simple name/password 146 authentication may suffice. In other cases, authentication 147 needs to be free from replay and other masquerade attacks. 149 Simple protected authentication, in which the password is 150 protected from replay by hashing with a time-stamp and random 151 number may be adequate. Strong authentication, using public key 152 cryptography may also be appropriate if the necessary strong 153 authentication infrastructure is in place. 155 The actual process of authentication is not within the scope of 156 this document. 158 Once the HOB is established, it provides a means of 159 automatically maintaining access point and policy information 160 relevant to the naming context in the subordinate DSA and to the 161 corresponding subordinate reference held in the superior DSA. 163 A related process is described in the Standards whereby the 164 reference from the superior to the subordinate DSA is a Non 165 Specific Subordinate Reference. This process is not within the 166 scope of the present document. 168 The objective of this document is to define capabilities and 169 constraints on support for DSP by DSAs so that DSAs will be able 170 to interwork using HOBs within the Directory. 172 It therefore profiles the following: 174 * The configuration of DSAs in preparation for establishment 175 of HOBs 177 * A superior DSA using a DOP establish-operational-binding 178 operation to create a subordinate naming context in order to 179 implement an add-entry operation in which the targetSystem 180 element is present 182 * A subordinate DSA responding to a DOP 183 establish-operational-binding operation 185 * Superior and subordinate DSAs as invokers and responders of 186 DOP modify-operational-binding operations 188 * Superior and subordinate DSAs as invokers and responders of 189 DOP terminate-operational-binding operations 191 DSAs supporting HOBs are REQUIRED by the base standards to 192 support DSP. 194 2. Scenario 196 DSAs may be configured by their administrative authorities (by 197 means outside the scope of the Directory standards) to allow 198 them to create or accept Hierarchical Operational Bindings. 200 Administrative Administrative 201 authority authority 202 \ / 203 +--------+ +-----------+ 204 |superior| |subordinate| 205 administr- | DSA | DSA | DSA | 206 ative user | * | | ^ | 207 creating DAP| /*\ | DOP | / \ | 208 new naming ====>| /***\ |<=======>| / \ | 209 context or DSP| ---^- | | ---*- | 210 or maintain- | sub | | /*\ | 211 ing existing | ref | | /***\ | 212 one +--------+ +-----------+ 214 Figure 1-DSA support of Hierarchical Operational Bindings 216 A DSA configured in this way may then (after suitable stimulus) 217 interact with another DSA using DOP operations. This stimulus 218 MAY be direct management action, or it MAY be DAP or DSP 219 protocol action. A particular stimulus is a request by an 220 administrative user to establish a new naming context (triangle 221 of asterisks at bottom of box for subordinate DSA). Another MAY 222 be an administrative authority action to coordinate two DSAs 223 which already contain a superior and a subordinate naming 224 context. 225 3. Definitions and abbreviations 227 3.1 Definitions 229 Many of the definitions used may be found in the Directory 230 Standards. Since not all of the definitions are to be found in 231 the Definitions clauses within the standards documents, 232 references are listed in Table 1 below. The "Part" reference 233 refers to the part number within ISO/IEC 9594 or its ITU-T 234 equivalent. 236 +-----------------------------------+----+-----------+ 237 | Term |Part| Reference | 238 +-----------------------------------+----+-----------+ 239 | administrative role | 2 | 13.3 | 240 | cooperative state | 2 | 22.1 | 241 | Directory Operational Binding | | | 242 | Management Protocol (DOP) | 2 | 11 | 243 | directory operational framework | 2 | 22.1 | 244 | Hierarchical Operational Binding | | | 245 | (HOB) | 4 | 3 | 246 | immediate superior reference | 2 | 18.1 | 247 | knowledge (information) | 2 | 18.1 | 248 | knowledge reference | 2 | 18.1 | 249 | master knowledge | 2 | 18.1 | 250 | name resolution | 4 | 3 | 251 | naming context | 4 | 17.1 | 252 | non-cooperative state | 2 | 22.1 | 253 | Non-specific Hierarchical | | | 254 | Operational Binding (NHOB) | 4 | 3 | 255 | Non-specific Subordinate | | | 256 | Reference (NSSR) | 2 | 18.1 | 257 | operational binding | 2 | 22.1 | 258 | operational binding establishment | 2 | 22.1 | 259 | operational binding instance | 2 | 22.1 | 260 | operational binding management | 2 | 22.1 | 261 | operational binding modification | 2 | 22.1 | 262 | operational binding termination | 2 | 22.1 | 263 | operational binding type | 2 | 22.1 | 264 | relevant hierarchical operation | | | 265 | binding (RHOB) | 4 | 3 | 266 | Simplified Access Control | 2 | 16 | 267 | subentry | 2 | 11.1 | 268 | subordinate DSA | 4 | 3 | 269 | subordinate reference | 2 | 18.1 | 270 | subrequest | 4 | 3 | 271 | superior DSA | 4 | 3 | 272 | target object name | 4 | 3 | 273 +-----------------------------------+----+-----------+ 274 Table 1: Definitions and references 276 3.2 Abbreviations 278 The following abbreviations are used as defined in the Directory 279 Standards or elsewhere: 281 ACSE Association Control Service Element 282 APDU Application Protocol Data Unit 283 ASN.1 Abstract Syntax Notation One 284 BAC Basic Access Control 285 DAP Directory Access Protocol 286 DIB Directory Information Base 287 DIT Directory Information Tree 288 DMD Directory Management Domain 289 DSA Directory System Agent 290 DOP Directory Operational Binding Management Protocol 291 DSE DSA specific entry 292 DSP Directory System Protocol 293 DUA Directory User Agent 294 EGDIR Expert Group on the Directory 295 EWOS European Workshop for Open Systems 296 HOB Hierarchical operation binding 297 IUT Implementation under test 298 NHOB Non-specific hierarchical operation binding 299 NSSR Non-Specific Subordinate Reference 300 PDU Protocol Data Unit 301 PICS Protocol Implementation Conformance Statement 302 POQ Partial outcome qualifier 303 RDN Relative Distinguished Name 304 RHOB Relevant hierarchical operation binding 305 ROSE Remote Operations Service Element 306 SAC Simplified Access Control 307 SPDU Session Protocol Data Unit 308 SSDU Session Service Data Unit 310 4. Conformance - Hierarchical Operational Bindings 312 This document specifies requirements upon DSA implementations to 313 achieve interworking when using HOBs. A claim of conformance to 314 this document is a claim that all requirements in the relevant 315 base standards are satisfied, and that all requirements in the 316 following clauses are satisfied. 318 4.1 Static Conformance Requirements 320 To conform to this document, DSA implementations MUST conform to 321 all mandatory requirements of clause 9.2 in ISO/IEC 9594-5:1993 322 (X.519), of Section 10 of ISO/IEC 9594-2:1993 (X.501), extended 323 by mandatory requirements of Clause 24 of ISO/IEC 9594-4:1993 324 (X.518), as applicable to a DSA implementing the 325 directoryOperationalBindingManagementAC application context, 326 including the requirements directly and indirectly referenced by 327 that clause. 329 NOTE. A DSA claiming conformance to the 330 directoryOperationalBindingManagementAC MUST also claim 331 conformance to the directorySystemAC (see X.518 clause 9.2.1 332 a)). 334 4.1.1 General capability 336 DSAs conformant with this document MUST be capable of: 338 1. Acting in both ROLE-A (superior DSA) and ROLE-B (subordinate 339 DSA), in accordance with X.518 clause 24.2, in order to 340 implement the procedures associated with the targetSystem 341 element of the DAP add-entry operation 343 2. When in ROLE-A (superior DSA), accepting an add-entry 344 operation specifying targetSystem, and carrying out the 345 procedures defined in X.518 clause 24.3 for the 346 establishment of a HOB. 348 DSAs SHOULD be capable of acting in ROLE-A (superior DSA), or 349 ROLE-B (subordinate DSA), or both, in accordance with X.518 350 clause 24.2, in order to implement a Hierarchical Operational 351 Binding in respect of a pre-existing subordinate naming context 352 which was established by local means. 354 DSAs conformant with this document MUST be able to tolerate the 355 case where they contain a superior or subordinate DSA, but no 356 HOB exists. 358 4.1.2 HOB acceptability 360 DSAs conformant with this document MUST be configurable to 361 Reject HOBs under the following circumstances, in order to 362 Permit administrative authorities sufficient control over 363 Hierarchical bindings: 365 1. A ROLE-A DSA conformant with this document MUST be 366 configurable to reject an add-entry operation specifying 367 targetSystem in respect of any specific DSA. In this case, 368 it MUST either ignore the targetSystem element or respond to 369 the invoker of the operation with a suitable error. The 370 latter capability is mandatory if target-system is specified 371 as a critical extension. 373 2. A ROLE-A DSA conformant with this document MUST be 374 configurable to reject an attempt to create a HOB when the 375 proposed new naming context for the DSA has a name which is 376 unacceptable when this is proposed by a ROLE-B DSA. It MUST 377 be possible for any specific name for an entry immediately 378 subordinate to entries already held by the DSA to be 379 configured as unacceptable in this sense, for the purposes 380 of conformance testing. 382 3. A ROLE-B DSA conformant with this document MUST be 383 configurable to reject a HOB when the naming context for the 384 DSA has a name which is unacceptable when this is proposed 385 by a ROLE-A DSA. It MUST be possible for any entry name 386 that is not superior or subordinate to entries already held 387 by the DSA to be configured as unacceptable in this sense, 388 for the purposes of conformance testing, possibly by 389 implementing a list of names which are acceptable. 391 4. A ROLE-B DSA conformant with this document MUST be 392 configurable to reject a HOB when this is proposed by any 393 specific DSA attempting to act as a ROLE-A DSA. 395 NOTE. In some cases, there may be a requirement for human 396 managers to interact (e.g. by telephone or Email) to accept or 397 reject a request for a HOB. 399 4.1.3 HOB operations 401 DSAs MUST support establishment, modification and termination 402 operations in both ROLE-A and ROLE-B, within limitations defined 403 in clause 4.2. 405 4.1.4 Information supported by HOBs 407 ROLE-A DSAs conformant with this document MUST support the 408 Supply and maintenance of all relevant administrative point and 409 Subentry information for each vertex between the root and the 410 Subordinate naming context (except when specified below as 411 optional). This includes: 413 * Access control information (both BAC and SAC) 415 * Subschema information (OPTIONALLY) 417 * Collective attribute information (OPTIONALLY) 419 ROLE-A and ROLE-B DSAs MUST support the supply and maintenance 420 Of their own access points. 422 ROLE-A DSAs are NOT REQUIRED to support the modification of a 423 HOB which would change the DN of the context prefix for the 424 subordinate naming context except that ROLE-A DSAs are REQUIRED 425 to support a change in RDN of the subordinate context prefix 426 (while retaining the DN of the superior entry). 428 ROLE-A DSAs are NOT REQUIRED to support the modification of a 429 HOB which would change the DN of the context prefix for the 430 Superior naming context without changing the DN of the context 431 prefix for the subordinate naming context (i.e. moving the 432 context prefix for the subordinate naming context up or down the 433 DIT). 435 ROLE-B DSAs are NOT REQUIRED to supply and maintain entry 436 information for the context prefix in the superior DSA (i.e. as 437 entryInfo in the SubordinateToSuperior establishment parameter - 438 see X.518 clause 24.4.1.2). If not supplied, the superior DSA 439 does not have the information necessary to make access control 440 decisions that take into account policies within the subordinate 441 DSA; it MAY be able to implement locally defined policies 442 instead. However, they SHOULD supply the entry information. 444 NOTE. If however they do so supply it, they MUST be capable of 445 maintaining it (see 4.1.5). 447 4.1.5 Established Hierarchical Bindings 449 After a hierarchical operational binding has been successfully 450 established, the following requirements are placed on ROLE-A and 451 ROLE-B DSAs: 453 1. ROLE-A DSAs MUST be capable of establishing a DOP 454 association, and using it to invoke a 455 modify-operational-binding operation consequent upon the 456 following stimuli: 458 * Any change in contextPrefixInfo as it would be 459 transmitted in modify-operational-binding argument 461 * Any change in the access point of the DSA 463 2. ROLE-B DSAs MUST similarly be capable of establishing a DOP 464 association, and using it to invoke a 465 modify-operational-binding operation consequent upon the 466 following stimuli: 468 * Any change in entryInfo within the scope of interest to 469 the ROLE-A DSA, to include object class and entryACI 470 (when present) 472 * Any change in the access point of the DSA 474 Either role MAY invoke a modify-operational-binding 475 operation under other circumstances, even when no change has 476 taken place, for example following a crash. 478 4.1.6 Security Level 480 Implementations MUST be able to carry out the peer entity 481 authentication of DSAs by the following ways: 483 * Simple authentication with unprotected password 485 The following methods of peer entity authentication are OPTIONAL 486 (see Note 2 below): 488 * Simple protected authentication 490 * Strong authentication 492 DSAs conformant with this document MUST be capable of rejecting 493 DOP binds that use no authentication, or that use simple 494 unprotected authentication without password. 496 Notes 498 1. Since HOBs establish trusted relationships between DSAs, 499 authentication MUST be adequately secure. Secure means of 500 authentication that counter observation and replay attacks, 501 such as simple protected authentication or strong 502 authentication using public key cryptography should be 503 considered. 505 2. The use of external authentication using the 506 externalProcedure element in accordance with ISO/IEC 507 9594-4:1993 (X.518) clause 11.1 and ISO/IEC 9594-3:1993 508 (X.511) clause 8.1.2 is outside the scope of this document. 510 4.1.7 Disclosure of HOB information 512 DSAs acting in ROLE-A or ROLE-B MUST be configurable to refuse 513 direct DAP or DSP access to any information received as a result 514 of the HOB, other than entryInfo by a ROLE-B DSA. 516 NOTE. This requirement states that the following information is 517 regarded as internal, although access to it MAY be required for 518 system management or diagnostic purposes, even when it can in 519 principle be formulated to provide attribute information: 521 * SuperiorToSubordinate.contextPrefixInfo 523 * SuperiorToSubordinate.immediateSuperiorInfo 525 * SubordinateToSuperior 527 4.1.8 Initiation by administrative intervention 529 DSAs MAY support the initiation of a HOB in respect of 530 a pre-existing naming context. If supported, initiation MUST be 531 possible by either the ROLE-A or the ROLE-B DSA creating a DOP 532 association and invoking an establish-operational-binding 533 operation conformant with HOB requirements. 535 Following successful establishment, each DSA conformant to this 536 document MUST support modify-operational-binding operations as 537 in clause 4.1.4. 539 4.1.9 Validity 541 Since a HOB represents the existence of bothe a superior and a 542 subordinate naming context, DSAs in ROLE-A and ROLE-B are NOT 543 REQUIRED to support validity other than the default validity for 544 the operational binding: 546 * Valid from now ... 548 * Until explicitly terminated 550 ROLE-A and ROLE-B DSAs MAY act always as if this 551 were the validity used (see 4.2.2). 553 4.1.10 Termination 555 A ROLE-A DSA MAY be capable of invoking a termination 556 operation for an active HOB. This can only occur as a 557 consequence of Administrative Authority action. 559 A ROLE-B DSA MUST be capable of invoking a termination operation 560 for an active HOB when the naming context is removed (e.g. by a 561 remove-entry operation for the context prefix). 563 A ROLE-B DSA MAY be capable of invoking a termination 564 operation for an active HOB when the naming context still 565 exists. 567 4.2 Dynamic Conformance Requirements 569 To conform to this document, implementations MUST conform to all 570 mandatory requirements of 9.2.3 and 7.5 in ISO/IEC 9594-5:1993 571 (X.519) for a DSA supporting the 572 directoryOperationalBindingManagementAC application context. 573 Implementations MUST conform to all procedures specified in the 574 directory base standards relating to Hierarchical Operational 575 Bindings, as amended by the corrigenda listed in clause 7 of 576 this document, as they relate to operations and protocol 577 elements for which support is claimed in the PICS. Attention is 578 drawn to the following clauses of ISO/IEC 9594-4:1993 (X.518): 580 * Add-entry operations affecting HOBs (clause 19.1.1) , 581 including those that add relevant subentries 583 * Remove-entry operations affecting HOBs (clause 19.1.2), 584 including those that remove relevant subentries 586 * Modify-entry operations affecting HOBs (clause 19.1.3), 587 including those that remove relevant subentries 589 * Modify-DN operations affecting HOBs (clause 19.1.4), 590 including those that change the names of relevant subentries 592 There are limitations on the support for modify-DN operations 593 (see 4.1.4). 595 4.2.1 ROLE-A Support - Establishment Parameters 597 4.2.1.1 Vertex 599 In the case of administrative points, the following information 600 MUST be supplied in contextPrefixInfo for each vertex: 602 * In admPointInfo, the administrative role attribute if 603 relevant (i.e. there is no ppp-specific point interposed 604 between the vertex and the new entry where ppp is any of the 605 three administrative purposes: access-control, subschema 606 administration, collective attributes) 608 * In admPointInfo, the access-control-scheme attribute if 609 relevant (i.e. there is no access control specific point 610 interposed between the vertex and the new entry) 612 * In subentryInfo, the complete information in all relevant 613 subentries (i.e. subentries for each administrative purpose 614 ppp where there is no ppp-specific point interposed between 615 the vertex and the new entry) 617 The accessPoints element MUST be present when the vertex 618 corresponds to the context prefix of the superior naming context 619 which is the subject of the HOB. However a ROLE-A DSA is 620 permitted to pass either an empty SET OF as 621 MasterAndShadowAccessPoints or a SET OF that contains only the 622 master access-point (i.e. a reference to itself). 624 If shadow access points are present in 625 MasterAndShadowAccessPoints, the master access-point MUST also 626 be present. 628 4.2.1.2 Entry information 630 When the HOB is initiated as a result of an add-entry operation, 631 the DSA MUST supply in SET OF Attribute the exact information 632 supplied by SET OF Attribute within the add-entry operation. 634 4.2.1.3 Immediate superior info 636 The ImmediateSuperiorInfo element MUST be supported, and MUST 637 contain the objectClass and entryACI attributes. 639 NOTES 641 1. The DSA MAY be configurable to not transmit this 642 element 644 2. The DSA MAY supply other attributes 646 4.2.2 Validity 648 Since a HOB of this kind represents a de-facto situation (i.e. 649 the presence or otherwise of a subordinate naming context), the 650 components of Validity are not relevant to practical operations. 652 Initiating DSAs SHOULD use the default (element is 653 absent), meaning valid from now until explicitly terminated. 655 Responding DSAs MAY ignore the element (i.e. treat 656 it as if the default had been received). 658 4.2.3 ROLE-B Support - Establishment Parameters 660 DSAs acting in ROLE-B MUST be capable of supporting: 662 1. Administrative information supplied in contextPrefixInfo, in 663 respect of some or all of the administrative purposes: 665 * Access control (MANDATORY) 667 * Subschema administration (SHOULD be 668 supported) 670 * Collective attributes (SHOULD be supported) 672 in accordance with the REQUIREMENTS of the Standards for: 674 * Simplified Access Control or Basic Access Control 676 * Administrative Areas 678 * Schema Administration 680 2. Knowledge information for an immediate-superior reference 681 supplied in accessPoints within contextPrefixInfo. 683 A DSA is NOT REQUIRED to implement the optimisation of the list 684 operation supported by ImmediateSuperiorInfo (X.518 clause 685 19.3.1.2.1 3 a), 24.1.4.2 Note). 687 A DSA MUST support the subordinateToSuperior value as follows: 689 * accessPoints MUST be supported, except that only support for 690 a master reference is REQUIRED (Shadow references wouldn't 691 be available at this stage, but they could be present for 692 the use in MODIFICATION-PARAMETERS). 694 * alias MAY be supported 696 * entryInfo MAY be supported 698 When entryInfo is supported, it MUST comprise at least: 700 * The objectClass attribute 702 * An entryACI attribute, synthesised as necessary to contain 703 all the ACI that is relevant to the access of the context 704 prefix. 706 The last of these is used to indicate all of the ACI relevant to 707 the entry which is derived from the context prefix's entry ACI 708 (if any) together with any precriptive ACI derived from the 709 context prefix's subentries (if any) and relevant to the context 710 prefix. The ACI values are simply gathered together to form a 711 synthesised attribute. This information can be supplied to 712 optimise the handling of access control for lists, and also to 714 regulate access to subordinate reference information. 715 Disclosing the latter could give rise to a breach of security, 716 and the entry ACI helps control this for the purposes of DAP or 717 DSP operations (which are outside the present scope). 719 This entryACI MAY be passed back even if SAC is to be used. 721 4.2.4 Modification Parameters 723 4.2.4.1 ROLE-A Parameters 725 Support MUST be as for establishment parameters, except that 726 entryInfo is absent in SuperiorToSubordinateModification (it is 727 otherwise identical to SuperiorToSubordinate). 729 4.2.4.2 ROLE-B Parameters 731 Support MUST be as for establishment parameters. 733 4.2.5 Termination 735 A ROLE-B DSA in receipt of a termination invoke from a ROLE-A 736 DSA MUST be capable of accepting the termination. However, 737 there is no requirement to remove the subordinate naming 738 context, or to change any of the administrative policies that 739 pre-existed before the termination. 741 A ROLE-B DSA MUST be capable of invoking a termination operation 742 for an active HOB when the naming context is removed (e.g. by a 743 remove-entry operation for the context prefix). 745 A ROLE-A DSA from a ROLE-A DSA in receipt of a termination 746 invoke MUST be capable of accepting the termination. 748 4.2.6 Rules of Extensibility for Result and Error Handling 750 Implementations MUST satisfy the rule of extensibility for 751 Result and error handling specified in clause 7.5 of ISO/IEC 752 9594-5:1993 (X.519). 754 4.2.7 Digital Signatures 756 Digital signatures are not supported by 1993 DOP operations 757 (although this anomaly is rectified by the 1997 Directory 758 standards). 760 4.2.8 Errors 762 Operational binding errors MUST be supported by ROLE-A and OLE-B 763 DSAs in conformance with X.501 clause 24.5. 765 5. Security considerations 767 HOBs permit an intimate relationship to exist between two DSAs; 768 the feature needs to be carefully protected. For this reason, 769 adequate authentication is REQUIRED, and DSAs need to be 770 designed to accept HOBs ONLY from suitably qualified sites. (See 771 the statements on authentication requirements in the 772 Introduction.) In addition, the initiation of a HOB is ONLY 773 tolerable when done by a qualified administrative user. 774 Protection from other users MAY be provided by Access Control or 775 other means. 777 By "adequate authentication" is meant "a means of authentication 778 which satisfies the requirements of the local Security Policy on 779 masquerade and related threats". 781 By "qualified administrative user" is meant a human party to 782 whom authority has been given by the owning organisation to 783 operate the DSA (or DSAs) involved, and for whom a suitable 784 means of authentication has been provided". 786 6. Summary of support 788 The following clause summarises the functional and protocol 789 support defined by this document. In the second column, the 790 letter "m" indicates that the requirement is MANDATORY. The 791 letter "o" indicates that the requirement is OPTIONAL. 793 +----------------------------------------------------------+---+ 794 | Support of both ROLE-A and ROLE-B in implementing | | 795 | the targetSystem element and procedure of add-entry | | 796 | to create a HOB | m | 797 +----------------------------------------------------------+---+ 798 | Support of ROLE-A or ROLE-B in implement a HOB in respect| | 799 | of a pre-existing subordinate naming context which was | | 800 | established by local means. | m | 801 +----------------------------------------------------------+---+ 802 | For a ROLE-A DSA, support of configuration to reject an | | 803 | add-entry operation specifying targetSystem in respect of| | 804 | any specific DSA. | m | 805 +----------------------------------------------------------+---+ 806 | DSAs conformant with this document MUST be able to | | 807 | tolerate the case where they contain a superior or | | 808 | subordinate DSA, but no HOB exists. | m | 809 +----------------------------------------------------------+---+ 810 | For a ROLE-A DSA, support of configuration to reject an | | 811 | attempt to create a HOB when the ROLE-B DSA proposes a | | 812 | new naming context with an unacceptable name | m | 813 +----------------------------------------------------------+---+ 814 | For a ROLE-B DSA, support of configuration to reject an | | 815 | attempt to create a HOB proposed by a ROLE-A DSA for a | | 816 | new naming context with a name unacceptable to it | m | 817 +----------------------------------------------------------+---+ 818 +----------------------------------------------------------+---+ 819 | For a ROLE-B DSA, support of configuration to reject a | | 820 | HOB proposed by any specific ROLE-A DSA | m | 821 +----------------------------------------------------------+---+ 822 | Support of establishment, modification, and termination | | 823 | operations in ROLE-A and ROLE-B, subject to clause 4.2 | m | 824 +----------------------------------------------------------+---+ 825 | Support of transfer of administrative point and subentry | | 826 | information by ROLE-A DSAs: Access control information | m | 827 +----------------------------------------------------------+---+ 828 | Support of transfer of administrative point and subentry | | 829 | information by ROLE-A DSAs: Subschema information | o | 830 +----------------------------------------------------------+---+ 831 | Support of transfer of administrative point and subentry | | 832 | information by ROLE-A DSAs: Collective attribute | | 833 | information | o | 834 +----------------------------------------------------------+---+ 835 | Support, by both ROLE-A and ROLE-B DSAs of the supply and| | 836 | maintenance of their own access points. | m | 837 +----------------------------------------------------------+---+ 838 | Support by ROLE-A of a change in RDN of the subordinate | | 839 | context prefix (retaining the DN of the superior entry) | m | 840 +----------------------------------------------------------+---+ 841 | Support by ROLE-A DSAs of establishing a DOP association,| | 842 | to invoke a modify-operational-binding operation after | | 843 | Any change in contextPrefixInfo | | 844 | Any change in the access point of the DSA | m | 845 +----------------------------------------------------------+---+ 846 | Support by ROLE-B DSAs of establishing a DOP association | | 847 | to invoke a modify-operational-binding operation after | | 848 | Any change in entryInfo as previously supplied | | 849 | Any change in the access point of the DSA | m | 850 +----------------------------------------------------------+---+ 851 | Support of DOP binds using simple authentication with | | 852 | unprotected password (this may be inadequate for some | | 853 | purposes, but is mandated as a minimal capability) | m | 854 +----------------------------------------------------------+---+ 855 | Support of DOP binds using simple protected | | 856 | authentication | o | 857 +----------------------------------------------------------+---+ 858 | Support of DOP binds using strong authentication | o | 859 +----------------------------------------------------------+---+ 860 | Capable of rejecting DOP binds that use no | | 861 | authentication, or that use simple unprotected | | 862 | authentication without password. | m | 863 +----------------------------------------------------------+---+ 864 | Support of configuration as ROLE-A or ROLE-B to refuse | | 865 | direct DAP or DSP access to information received using | | 866 | other than entryInfo supplied by a ROLE-B DSA. | m | 867 +----------------------------------------------------------+---+ 868 +----------------------------------------------------------+---+ 869 | Support by a ROLE-A or ROLE-B DSA of creation of a HOB | | 870 | in respect of a pre-existing naming context, and | | 871 | subsequent support of modify-operational-binding | | 872 | operations | m | 873 +----------------------------------------------------------+---+ 874 | Support by a ROLE-B DSA of a termination operation for | | 875 | an active HOB when the naming context is removed | m | 876 +----------------------------------------------------------+---+ 877 | Support by a ROLE-B DSA of a termination operation for | | 878 | an active HOB when the naming context still exists. | o | 879 +----------------------------------------------------------+---+ 880 | Support of specificHierarchicalBindingID | m | 881 +----------------------------------------------------------+---+ 882 | Support of the following DOP operations: | | 883 | EstablishOperationalBinding | | 884 | ModifyOperationalBinding | | 885 | TerminateOperationalBinding, | m | 886 | as used for hierarchical operational bindings | | 887 +----------------------------------------------------------+---+ 888 | Support of the following in In DirectoryBindArgument and | | 889 | DirectoryBindResult, as used within DOP: | | 890 | credentials | | 891 | simple | | 892 | name | | 893 | password | | 894 | as used for hierarchical operational bindings | m | 895 +----------------------------------------------------------+---+ 896 | Support of the following in Establish Operational | | 897 | Binding: | | 898 | bindingID - the initiator MUST be able to place an Id | | 899 | here | | 900 | roleA-initiates (with SuperiorToSubordinate) | m | 901 +----------------------------------------------------------+---+ 902 | If roleB-initiates is supported, support of | | 903 | SubordinateToSuperior | m | 904 +----------------------------------------------------------+---+ 905 | In Establish Operational Binding Argument Result, support| | 906 | of the following: | | 907 | bindingID | | 908 | initiator | m | 909 +----------------------------------------------------------+---+ 911 7. Transport Mappings 913 Requirements on transport mappings are outside the scope of this 914 document. 916 8. References 918 The following Directory standards are particularly relevant: 920 [1] ISO/IEC 9594-2:1993 (X.501): Information Technology -- Open 921 Systems Interconnection -- The Directory: Models. 923 [2] ISO/IEC 9594-3:1993 (X.511): Information Technology -- Open 924 Systems Interconnection -- The Directory: Abstract Service 925 Definition. 927 [3] ISO/IEC 9594-4:1993 (X.518): Information Technology -- Open 928 Systems Interconnection -- The Directory: Procedures for 929 Distributed Operations. 931 [4] ISO/IEC 9594-5:1993 (X.519): Information Technology -- Open 932 Systems Interconnection -- The Directory: Protocol 933 Specifications. 935 The amendments and corrigenda as listed below are considered as 936 normative references by this document. 938 +----+-----------------------------+---------------------------+ 939 | 1 | ISO/IEC 9594-2:1993 (X.501) | Cor.1: 1995 | 940 | 2 | ISO/IEC 9594-2:1993 (X.501) | Draft Cor.2: 1995 | 941 | 3 | ISO/IEC 9594-8:1993 (X.509) | Cor.1: 1995 | 942 | 4 | ISO/IEC 9594-8:1993 (X.509) | Cor.2: 1995 | 943 | 5 | ISO/IEC 9594-8:1993 (X.509) | Draft Cor.3: 1995 | 944 | 6 | ISO/IEC 9594-3:1993 (X.511) | Cor.1: 1995 | 945 | 7 | ISO/IEC 9594-3:1993 (X.511) | Draft Cor.2: 1995 | 946 | 8 | ISO/IEC 9594-4:1993 (X.518) | Cor.1: 1995 | 947 | 9 | ISO/IEC 9594-4:1993 (X.518) | Draft Cor.2: 1995 | 948 | 10 | ISO/IEC 9594-5:1993 (X.519) | Cor.1: 1995 | 949 | 11 | ISO/IEC 9594-6:1993 (X.520) | Cor.1: 1995 | 950 | 12 | ISO/IEC 9594-9:1993 (X.525) | Cor.1: 1995 | 951 | 13 | ISO/IEC 9594-9:1993 (X.525) | Draft Cor.2: 1995 | 952 +----+-----------------------------+---------------------------+ 954 8. Authors' Addresses 956 Anthony Hodson (Editor for ISSS EGDIR) 957 XdotD Associates 958 Spring Lanes House 959 Holly Spring Lane 960 Bracknell, Berkshire, ENGLAND 961 Email: aeh@xdotd.demon.co.uk 962 Erik Andersen (ISSS EGDIR Chairman) 963 Fischer & Lorenz 964 Tuborg Parkvej 10 965 DK2000 Hellerup, DENMARK 966 Email: era@fl.dk 968 Keith Richardson 969 ICL 970 High Performance Systems 971 Wenlock Way, West Gorton 972 Manchester M12 5DR ENGLAND 973 Email: k.richardson@man0523.wins.icl.co.uk 975 Louis Visser 976 Netherlands Normalisatie-instituut 977 Kalfjeslaan 2 978 Delft, NETHERLANDS, 979 Email: l.visser@nni.nl 981 Patrick Fantou 982 Siemens Nixdorf Informationssysteme AG 983 ASW BA COM2 984 Otto-Hahn-Ring 6 985 D-81739 MUNICH GERMANY 986 Email: Patrick.Fantou@mch.sni.de 988 Jacqueline Pasquerau 989 EDFGDS 990 STI 991 21 Rue Joseph Bara 992 92132 Issy les Moulineaux CEDEX 993 FRANCE 994 Email: jacqueline.pasquereau@edfgds.fr