idnits 2.17.1 draft-ietf-ldapext-acl-model-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 62 longer pages, the longest (page 2) being 200 lines 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([REQTS], [Bradner97]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1155 has weird spacing: '...ding to the "...' == Line 2373 has weird spacing: '...to the sn att...' == Line 2470 has weird spacing: '...ontrols field...' == Line 2958 has weird spacing: '...nta.com mai...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (29 June 2001) is 8335 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) -- Looks like a reference, but probably isn't: '1' on line 2547 -- Looks like a reference, but probably isn't: '2' on line 2539 == Missing Reference: 'APPLICATION 3' is mentioned on line 1370, but not defined == Missing Reference: 'APPLICATION 6' is mentioned on line 1531, but not defined == Missing Reference: 'APPLICATION 8' is mentioned on line 1574, but not defined == Missing Reference: 'APPLICATION 10' is mentioned on line 1612, but not defined == Missing Reference: 'APPLICATION 12' is mentioned on line 1637, but not defined -- Looks like a reference, but probably isn't: '0' on line 2546 == Missing Reference: 'APPLICATION 14' is mentioned on line 1693, but not defined == Missing Reference: 'APPLICATION 16' is mentioned on line 1716, but not defined == Missing Reference: 'APPLICATION 23' is mentioned on line 1726, but not defined == Unused Reference: 'ATTR' is defined on line 2890, but no explicit reference was found in the text == Unused Reference: 'DirCompMatch' is defined on line 2903, but no explicit reference was found in the text == Unused Reference: 'ECMA' is defined on line 2907, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2828 (ref. 'ATTACK') (Obsoleted by RFC 4949) ** Obsolete normative reference: RFC 2252 (ref. 'ATTR') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) == Outdated reference: A later version (-02) exists of draft-zeilenga-auth-lvl-01 -- Possible downref: Normative reference to a draft: ref. 'AUTHMAP' ** Obsolete normative reference: RFC 2829 (ref. 'AuthMeth') (Obsoleted by RFC 4510, RFC 4513) == Outdated reference: A later version (-11) exists of draft-legg-ldapext-component-matching-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'ECMA' ** Obsolete normative reference: RFC 2373 (ref. 'IPV6') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2596 (ref. 'LangCode') (Obsoleted by RFC 3866) ** Obsolete normative reference: RFC 2251 (ref. 'LDAPv3') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Downref: Normative reference to an Informational RFC: RFC 2820 (ref. 'REQTS') -- Possible downref: Normative reference to a draft: ref. 'SUBENTRY' ** Obsolete normative reference: RFC 2253 (ref. 'UTF') (Obsoleted by RFC 4510, RFC 4514) -- Possible downref: Non-RFC (?) normative reference: ref. 'X501' -- Possible downref: Non-RFC (?) normative reference: ref. 'X511' Summary: 16 errors (**), 0 flaws (~~), 21 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft E. Stokes 3 LDAP Extensions WG B. Blakley 4 Intended Category: Standards Track Tivoli Systems 5 Expires: 29 December 2001 R. Byrne 6 Sun Microsystems 7 R. Huber 8 AT&T Laboratories 9 D. Rinkevich 10 Momenta 11 29 June 2001 13 Access Control Model for LDAPv3 14 16 STATUS OF THIS MEMO 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other groups 23 may also distribute working documents as Internet-Drafts. Internet- 24 Drafts are draft documents valid for a maximum of six months and may be 25 updated, replaced, or obsoleted by other documents at any time. It is 26 inappropriate to use Internet-Drafts as reference material or to cite 27 them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Comments and suggestions on this document are encouraged. Comments on 36 this document should be sent to the LDAPEXT working group discussion 37 list: 39 ietf-ldapext@netscape.com 41 COPYRIGHT NOTICE 43 Copyright (C) The Internet Society (2000). All Rights Reserved. 45 ABSTRACT 47 This document describes the access control model for the Lightweight 48 Directory Application Protocol V3 (LDAPv3) directory service. It 49 includes a description of the model, the schema for the model, and the 50 LDAP control to the LDAP protocol. The current LDAP APIs are sufficient 51 for the access control operations. A separate requirements document for 52 access control exists [REQTS]. The access control model used the 53 requirements document as a guideline for the development of this 54 specification and are reflected in this specification to the extent that 55 the working group could agree on an access control model. 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" used in this document 59 are to be interpreted as described in [Bradner97]. 61 1. Introduction 63 The ability to securely access (replicate and distribute) directory 64 information throughout the network is necessary for successful 65 deployment. LDAP's acceptance as an access protocol for directory 66 information is driving the need to provide an access control model 67 definition for LDAP directory content among servers within an enterprise 68 and the Internet. Currently LDAP does not define an access control 69 model, but one is needed to ensure consistent secure access, 70 replication, and management across heterogeneous LDAP implementations. 71 The major objective is to provide a simple, usable, and implementable, 72 but secure and efficient access control model for LDAP accessible 73 directory content while also providing the appropriate flexibility to 74 meet the needs of both the Internet and enterprise environments and 75 policies. This document defines the model, the schema, and the LDAP 76 control. 78 This model does not (and cannot) fully specify the behavior of the 79 Access Control Model in a distributed environment (e.g. propagating 80 access control information across servers and ACI administration) 81 because there is no LDAP standard defining how to distribute directory 82 data between LDAP servers. The behavior of the Access Control Model in 83 distributed environments is beyond the scope of this model. 85 The following topics are deemed interesting and useful for future work, 86 but are also beyond the scope of this model: 88 - Permissions based on object class 90 - Application permissions 92 - How to get initial entryACI and subtreeACI attributes in the 93 directory is server specific 95 - Use of prescriptive ACIs and scoping via use of a ldapACISubEntry 97 - Required permissions for LDAP extended operations and LDAP 98 controls, such as a proxy permission and permission extensibility 100 - The access rights required for the creation of the first entry in 101 the directory 103 - filter use in ACI 105 - Mapping of SASL authentication identities (whose form is mechanism 106 specific) to LDAP authorization identities (which are used for 107 access control purposes) 109 2. The LDAPv3 Access Control Model 111 Access Control mechanisms evaluate requests for access to protected 112 resources and make decisions about whether those requests should be 113 granted or denied. In order to make a grant/deny decision about a 114 request for access to a protected resource, an access control mechanism 115 needs to evaluate policy data. This policy data describes security- 116 relevant characteristics of the requesting subject and the rules which 117 govern the use of the target object. 119 No mechanism is defined in this document for storage of access control 120 information at the server beyond indicating that the attribute holding 121 access control information is an operational attribute. 123 The access control model defines 125 - What flows on the wire for interoperability 127 The existing LDAP protocol flows for ldap operations are used to 128 manipulate access control information. These same flows on the wire 129 apply when ACI is transmitted during replication. A set of 130 permissions and their semantics with respect to ldap operations is 131 defined. The permissions parallel the defined set of ldap 132 operations. Encoding of access control information on the wire is 133 per the LDAPv3 specifications. 135 There is a LDAP control defined, GetEffectiveRights. LDAP clients 136 use the control to manage and administer access control policy 137 enforced by LDAP servers. 139 Servers may store access control information in any way they 140 choose. In particular, servers may use the access control 141 mechanisms of their datastores to store and enforce LDAP access 142 control, or they may implement/exploit access control managers 143 external to their datastores. Datastores and external access 144 control managers MAY implement any access control rule syntax and 145 semantics they choose, but the semantics MUST be compatible with 146 those defined in the section titled "Required Permissions for Each 147 LDAP Operation". 149 - Attributes and classes for application portability of access 150 control information. Portable (LDAP) applications should only use 151 the ACI in this model. 153 Two access control information attributes (entryACI and subtreeACI) 154 for application portability. These attributes are used as input to 155 the LDAP APIs so access control information can be addressed 156 uniformly independent of how that information is accessed and 157 stored at the server. These same attributes appear in LDIF output 158 for interchange of access control information. 160 An access control information subentry class (ldapACISubEntry) and 161 a set of attributes (supportedAccessControlSchemes which is used in 162 the rootDSE, and accessControlSchemes which is used in the subentry 163 ldapACISubEntry) to identity the access control mechanisms 164 supported by a server and in a given part of the namespace, 165 respectively. 167 - A mechanism to control access to access control information: The 168 access control information operational attributes, entryACI and 169 subtreeACI, are also used to control access to access control 170 information (controls access to itself). How to get initial 171 entryACI and subtreeACI attributes in the directory is server 172 specific and beyond the scope of this model. 174 Servers can support multiple access control mechanisms, but MUST be 175 capable of supporting the LDAP Mechanism in the DIT scoped by the 176 rootDSE (entire server's DIT) for that server and SHOULD be capable of 177 supporting the LDAP mechanism in an arbitrary part (subtree) of the DIT. 179 The accessControlSchemes attribute in the ldapACISubEntry indicates 180 which access control mechanisms are in effect for the scope of that 181 ldapACISubEntry. The supportedAccessControlSchemes attribute in the 182 rootDSE indicates which access control mechanisms are supported by the 183 server; those mechanisms are in effect in that server's DIT unless 184 overridden by a mechanism defined in a ldapACISubEntry elsewhere in that 185 DIT. 187 Changing the value(s) of either the supportedAccessControlSchemes or 188 accessControlSchemes attributes changes the mechanism(s) in effect for 189 the scope of those attributes (where scope is either that of the rootDSE 190 or ldapACISubEntry). 192 Through the use of the supportedAccessControlSchemes attribute in the 193 rootDSE and the accessControlSchemes attribute in the ldapACISubEntry, 194 it is possible to run multiple mechanisms in either the same subtree or 195 separate subtrees. This might occur if the underlying datastore for the 196 directory was accessible via LDAP and other applications. In this case, 197 LDAP access should always be subjects to the LDAP access controls 198 described in this document. 200 3. Access Control Mechanism Attributes 202 Two attributes are defined to identify which access control mechanisms 203 are supported by a given server and by a given subtree: 204 supportedAccessControlSchemes and accessControlSchemes. (We chose these 205 names based on the X.500 attribute, AccessControlScheme which is 206 single-valued and defined in X.501). 208 3.1 Root DSE Attribute for Access Control Mechanism 210 The server advertises which access control mechanisms it supports by 211 inclusion of the 'supportedAccessControlSchemes' attribute in the root 212 DSE. This attribute is a list of OIDs, each of which identify an access 213 control mechanism supported by the server. By default, these are also 214 the mechanisms in effect in subtrees beneath the root in that server 215 unless overridden by a ldapACISubEntry (see section "Subentry Class 216 Access Control Mechanism"). 218 ( 219 NAME 'supportedAccessControlSchemes' 220 DESC list of access control mechanisms supported 221 by this directory server 222 EQUALITY objectIdentifierMatch 223 SYNTAX OID 224 USAGE dSAOperation 225 ) 227 The access control mechanism defined is: 228 LDAPv3 230 Other vendor access control mechanisms MAY be defined (by OID) and are 231 the responsibility of those vendors to provide the definition and OID. 233 3.2 Subentry Class Access Control Mechanism 235 A given naming context MUST provide information about which access 236 control mechanisms are in effect for that portion of the namespace. 237 This information is contained in a subentry (ldapACISubEntry class), 238 derived from [SUBENTRY]. ldapACISubEntry MAY be used to define the 239 scope of an access control mechanism. The value(s) held in the rootDSE 240 attribute, supportedAccessControlSchemes, are the mechanisms in effect 241 in subtrees beneath the root in that server unless overridden in a 242 ldapACISubEntry further down the tree held by that server. The scope of 243 that ldapACISubEntry is to the end of the subtree held by that server or 244 until another ldapACISubEntry is encountered in that subtree held by 245 that server. The ldapACISubEntry class is defined as: 247 ( 248 NAME 'ldapACISubEntry' 249 DESC 'LDAP ACI Subentry class' 250 SUP ldapSubEntry STRUCTURAL 251 MUST ( accessControlSchemes ) 252 ) 254 The accessControlSchemes attribute MUST be in each ldapACISubEntry entry 255 associated with a naming context whose access control mechanism is 256 different from adjacent naming contexts supported by that directory 257 server. accessControlSchemes lists the values (list of OIDs) that 258 define the access control mechanisms in effect for the scope of that 259 ldap access control subentry (either until another ldapACISubEntry is 260 encountered in that subtree or end of subtree is reached on the server). 261 Although, in general, this attribute will define only a single mechanism 262 (single value), more than one mechanism MAY be in effect for the scope 263 of that subentry. 265 ( 266 NAME 'accessControlSchemes' 267 DESC list of access control mechanisms supported 268 in this subtree 269 EQUALITY objectIdentifierMatch 270 SYNTAX OID 271 USAGE dSAOperation 272 ) 274 4. The Access Control Information Attributes, Syntax, and Rules 276 The access control information syntax and attributes, entryACI and 277 subtreeACI, are defined as: 279 ( 280 DESC 'attribute syntax for LDAP access control information' 281 ) 283 ( 284 NAME 'entryACI' 285 DESC 'ldap access control information, scope of entry' 286 EQUALITY directoryComponentsMatch 287 SYNTAX 288 USAGE directoryOperation 289 ) 291 ( 292 NAME 'subtreeACI' 293 DESC 'ldap access control information, scope of subtree' 294 EQUALITY directoryComponentsMatch 295 SYNTAX 296 USAGE directoryOperation 298 ) 300 Section 4.1 defines the ABNF and ASN.1 for these attributes, entryACI 301 and subtreeACI. 303 The intent of the attribute definitions is to define a common 304 interchange format and have a separation of responsibilities to allow 305 different people to administer the different attribute types. (X.500 306 overcomes this by allowing access control on a per-value basis, which is 307 complex). Any given LDAP server should be able to translate the defined 308 attribute into meaningful requests. Each server should be able to 309 understand the attribute; there should not be any ambiguity into what 310 any part of the syntax means. 312 While the end goal is to have a common behavior model between different 313 LDAP server implementations, the attribute definitions alone will not 314 ensure identical ACL processing behavior between servers. Applicability 315 and precedence rules for making access decisions are defined later in 316 this section. The semantics of how a server interprets the ACI syntax 317 are defined in the "Required Permissions for Each LDAP Operation" 318 section of this document. Additionally, while the server must recognize 319 and act on the attribute when received over the wire, there are no 320 requirements for the server to physically store these attributes in this 321 form. 323 The attribute definitions maintain an assumption that the receiving 324 server supports ACI inheritance within the security model. If the server 325 does not support inheritance, the receiving server must expand any 326 inherited information based on the scope flag. 328 The attributes are defined so access control information (ACI) can be 329 addressed in a server in an implementation independent manner. These 330 attributes are used in typical LDAP APIs, in LDIF output of ACI and in 331 transfer of ACI during replication. These attributes may be queried or 332 set on all directory objects. The ABNF and definitions are given below. 334 4.1 The ABNF and ASN.1 336 4.1.1 ACI UTF-8 String Representation 338 The LDAP string encoding of values of the ACI syntax () 339 is described by the following ABNF [ABNF]. This string representation 340 MUST be supported. 342 ACI = rights "#" attr "#" generalSubject 344 rights = (("grant:" / "deny:") permissions) / 345 ("grant:" permissions ";deny:" permissions) 347 permissions = 1*(permission) 349 permission = "a" / ; add 350 "d" / ; delete 351 "e" / ; export 352 "i" / ; import 353 "n" / ; renameDN 354 "b" / ; browseDN 355 "v" / ; view (entry level read permission) 356 "t" / ; returnDN 357 "r" / ; read 358 "s" / ; search filter 359 "p" / ; search filter (presence only) 360 "w" / ; write (mod-add) 361 "o" / ; obliterate (mod-del) 362 "c" / ; compare 363 "m" / ; make 364 "u" / ; unveil (disclose on error permission) 365 "g" ; getEffectiveRights 367 ; permissions r, w, o, s, p, c, m work on attributes 368 ; permissions a, d, e, i, n, b, v, t, u, g work on entries 369 ; permissions for attributes and permissions for entries are 370 ; never found in a single ACI 372 attr = "[all]" / "[entry]" / (attribute *("," attribute)) 374 attribute = AttributeDescription 375 ; The rule is defined 376 ; in Section 4.1.5 of [LDAPv3] 378 generalSubject = context pureSubject 380 context = "authnLevel:" authnLevel ":" 382 pureSubject = anySubject / machineSubject / idBasedSubject 384 anySubject = "public:" 386 machineSubject = "ipAddress:" ipAddressRange *( "," ipAddressRange ) / 387 "dns:" partialdomainname *( "," partialdomainname ) 389 partialdomainname = [ "*." ] domainname 391 idBasedSubject = thisSubject / 392 oneSubject / 393 setOfSubjects 395 thisSubject = "this:" 396 oneSubject = ( "authzId-" authzId ) 397 setOfSubjects = ( "role:" dn ) / 398 ( "group:" dn ) / 399 ( "subtree:" dn ) 401 authnLevel = "none" / 402 "weak" / 403 "limited" / 404 "strong" 406 ; The rule is defined in [AuthMeth]. It is 407 ; repeated below for convenience. 409 authzId = dnAuthzId / uAuthzId 411 ; distinguished-name-based authz id. 412 dnAuthzId = "dn:" dn 414 dn = utf8string ; with syntax defined in [UTF] 416 ; unspecified userid, UTF-8 encoded. 417 uAuthzId = "u:" userid 418 userid = utf8string ; syntax unspecified 419 ; A utf8string is defined to be the UTF-8 encoding of 420 ; one or more ISO 10646 characters. 422 ipAddress = IPv6address 424 ; following is excerpted from [IPV6] 425 IPv6address = hexpart [ ":" IPv4address ] 426 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 428 hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] 429 hexseq = hex4 *( ":" hex4) 430 hex4 = 1*4HEXDIG 432 ipAddressRange = ipAddress [ HYPHEN ipAddress ] ; IPv6 address range 434 domainname = domaincomponent *( "." domaincomponent ) 436 OUTER = ALPHA / DIGIT 437 INNER = ALPHA / DIGIT / HYPHEN 438 HYPHEN = %x2D 439 domaincomponent = OUTER [ *61( INNER ) OUTER ] 441 Note that the colon following the "public" and "this" subject options 442 exist only to simplify string parsing. 444 If an ACI is attempted to be added with an authz that is not understood, 445 then the server MUST reject that entryACI or subEntryACI value. This 446 clarifies the statement in [AuthMeth] that allows for authzId may be 447 expanded in the future. 449 See section titled 'ACI Examples' for examples of the string 450 representation. 452 4.1.2 ACI Binary Representation 454 The ASN.1 type ACI is used to represent this syntax when transferred in 455 binary form. This binary form SHOULD be supported. 457 LDAP-Access-Control-Model 458 DEFINITIONS EXTENSIBILITY IMPLIED ::= 459 BEGIN 461 IMPORTS 462 AttributeType, DistinguishedName, CONTEXT 463 FROM InformationFramework; -- from [X501] 465 ACI ::= SEQUENCE { 466 rights SEQUENCE { 467 grant Permissions OPTIONAL, 468 deny [1] Permissions OPTIONAL } 469 (WITH COMPONENTS { ..., grant PRESENT } | 470 WITH COMPONENTS { ..., deny PRESENT }), 471 -- at least one of grant or deny must be present -- 472 attr CHOICE { 473 all NULL, 474 entry [1] NULL, 475 attributes SET (1..MAX) OF AttributeTypeAndOptions }, 476 authnLevel ::= ENUMERATED { 477 none (0), 478 weak (1), 479 limited (2), 480 strong (3)} 481 subject GeneralSubject 482 } 484 -- An X.500 representation for an LDAP Attribute Description -- 485 AttributeTypeAndOptions ::= SEQUENCE { 486 type AttributeType, 487 type-name UTF8String OPTIONAL, 488 -- A hint of what LDAP textual name to use when encoding an 489 -- AttributeTypeAndOptions as an . 490 options SEQUENCE SIZE (1..MAX) OF CONTEXT.&Assertion OPTIONAL 491 -- A future revision will constrain CONTEXT.&Assertion to be 492 -- the context assertion syntax of the CONTEXT information 493 -- object defined by the X.500 working group to represent 494 -- LDAP attribute options in the X.500 protocols. 495 -- This is likely to be the UTF8String type. 496 } 498 GeneralSubject ::= CHOICE { 499 anySubject NULL, 500 machineSubject [1] MachineSubject, 501 idBasedSubject [2] IDBasedSubject 502 -- may be expanded per [AuthMeth] -- 503 } 505 MachineSubject ::= CHOICE { 506 ipAddress IPAddress, 507 dns [1] DomainName 508 } 510 IPAddress ::= UTF8String 512 -- The character contents of an IPAddress string are encoded 513 -- according to the rule in Section 4.1.1. 515 DomainName ::= UTF8String 517 -- The character contents of a DomainName string are encoded 518 -- according to the rule in Section 4.1.1. 520 IDBasedSubject ::= CHOICE { 521 thisSubject NULL, 522 oneSubject [1] OneSubject, 523 setOfSubjects [2] SetOfSubjects 524 } 526 OneSubject ::= CHOICE { 527 dn DistinguishedName, 528 user UTF8String 529 } 531 SetOfSubjects ::= CHOICE { 532 role DistinguishedName, 533 group [1] DistinguishedName, 534 subtree [2] DistinguishedName 535 } 537 Permissions ::= BIT STRING { 538 add (0), 539 delete (1), 540 export (2), 541 import (3), 542 renameDN (4), 543 browseDN (5), 544 viewEntry (6), 545 returnDN (7), 546 read (8), 547 search (9), 548 searchPresence (10), 549 write (11), 550 obliterate (12), 551 compare (13), 552 make (14), 553 unveil (15), 554 getEffectiveRights (16) 555 (CONSTRAINED BY { -- at least one bit must be set -- }) 556 } 558 -- permissions read, write, obliterate, search, 559 -- searchPresence, compare, make work on attributes 560 -- permissions add, delete, export, import, renameDN, 561 -- browseDN, viewEntry, returnDN, unveil, 562 -- getEffectiveRights work on entries 564 END 566 4.2 The Components of entryACI and subtreeACI Attributes 568 This section defines components that comprise the access control 569 information attributes, entryACI and subtreeACI. 571 The access control information in the entryACI attribute applies only to 572 the entry in which it is contained. 574 The access control information in the subtreeACI attribute applies to 575 each entry down the subtree unless it is overridden by an entry-specific 576 entryACI whose values are more specific or another subtreeACI lower in 577 the tree. 579 Use of prescriptive ACIs and scoping via use of a ldapACISubEntry is 580 outside the scope of this document. 582 4.2.1 Access Rights and Permissions 584 Access rights can apply to an entire object or to attributes of the 585 object. Access can be granted or denied. Either or both of the actions 586 "grant" | "deny" may be used when creating or updating entryACI and 587 subtreeACI. 589 Each of the LDAP access permissions are discrete. One permission does 590 not imply another permission. The permissions which apply to attributes 591 and the entry parallel the type of ldap operations that can be 592 performed. 594 Permissions which apply to attributes: 596 r Read Read attribute values 597 w Write Modify-add values 598 o Obliterate Modify-delete values 599 s Search Search entries with specified 600 attributes 601 p searchPresence Presence only filters 602 c Compare Compare attributes 603 m Make Make attributes on a new entry below 604 this entry 606 1. r Read 608 If granted, permits attributes and values to be returned in a read 609 or search operation. 611 2. w Write 613 If granted, permits attributes and values to be added in a 614 modify-add operation. 616 3. o Obliterate 618 If granted, permits attributes and values to be deleted in a 619 modify-delete operation. 621 4. s Search 623 If granted, permits attributes and values to be included in the 624 search filter of a search operation. 626 5. c Compare 628 If granted, permits attributes and value to be used in a compare 629 operation. 631 6. p SearchPresence 633 If granted permits attributes and values to be included in 634 presence tests in a search filter. 636 7. m Make 638 The attribute permission "m" is required for all attributes that 639 are placed on an object when it is created. Just as the "w" and 640 "o" permissions are used in the Modify operation, the "m" 641 permission is used in the Add operation. Additionally, note that 642 "w" and "o" have no bearing on the Add operation and "m" has no 643 bearing on the Modify operation. Since a new object does not yet 644 exist, the "a" and "m" permissions needed to create it must be 645 granted on the new object's parent. This differs from "w" and "o" 646 which must be granted on the object being modified. The "m" 647 permission is distinct and separate from the "w" and "o" 648 permissions so that there is no conflict between the permissions 649 needed to add new children to an entry and the permissions needed 650 to modify existing children of the same entry. 652 Note: Modify-replace values of an attribute require both "w" and "o" 653 permission. 655 Permissions that apply to an entire entry: 657 a Add Add an entry below this entry 658 d Delete Delete this entry 659 e Export Export entry & subordinates to new 660 location 661 i Import Import entry & subordinates below this 662 entry from some location 663 n RenameDN Rename an entry's DN 664 b BrowseDN Browse an entry's DN 665 v ViewEntry A read level entry permission 666 t ReturnDN Allows DN of entry to be disclosed in 667 an operation result 668 u Unveil This is the discloseOnError permission 669 g GetEffectiveRights This is get effective rights 670 permission 672 1. a Add 674 If granted, permits creation of an entry in the DIT subject to 675 access control on all attributes and values to be placed in the 676 new entry at time of creation. In order to add an entry, 677 permission must also be granted to add all attributes that exist 678 in the add operation. 680 2. d Delete 682 If granted, permits the entry to be removed from the DIT 683 regardless of controls on attributes within the entry. Delete 684 only works on leaf entries (same as X.500). 686 3. e Export 688 If granted, permits an entry and its subordinates (if any) to be 689 exported; that is, removed from the current location and placed in 690 a new location subject to the granting of suitable permission at 691 the destination. If the last RDN is changed, Rename is also 692 required at the current location. In order to export an entry or 693 its subordinates, there are no prerequisite permissions to 694 contained attributes, including the RDN attributes; this is true 695 even when the operation causes new attribute values to be added or 696 removed as the result of the changes of RDN. 698 4. i Import 700 If granted, permits an entry and its subordinates (if any) to be 701 imported; that is, removed from some other location and placed 702 below the location to which the permission applies subject to the 703 granting of suitable permissions at and below the source location. 704 In order to import an entry or its subordinates, there are no 705 prerequisite permissions to contained attributes, including the 706 RDN attributes; this is true even when the operation causes new 707 attribute values to be added or removed as the result of the 708 changes of RDN. 710 5. n RenameDN 712 Granting Rename is necessary for an entry to be renamed with a new 713 RDN. There are many cases here surrounding the use of this 714 permission. See the section on 'Modify DN Operation'. 716 6. b BrowseDN 718 If granted, permits entries to be accessed using directory 719 operations which do not explicitly provide the name of the entry. 721 7. v ViewEntry 723 If granted, permits entries to be accessed. This entry level read 724 permission is useful as it is not dependent on the scope or 725 aliasing properties of the entry. 727 8. t ReturnDN 729 If granted, allows the distinguished name of the entry to be 730 disclosed in the operation result. 732 9. u Unveil 734 If granted, allows the presence of the entry to be disclosed in 735 the case where access is denied to the entry according to the 736 access control rules. 738 10. g getEffectiveRights 740 If granted, allows the effective rights on that entry and the 741 attributes within that entry to be returned, for _any_ subject. 743 4.2.2 Attributes 745 Attribute describes an attribute name in the form of a dotted decimal 746 OID for that . If the string (OID) refers to an attribute not 747 defined in the given server's schema, the server SHOULD report an error. 748 The use of "[entry]" or "[all]" helps to focus the permissions to either 749 entry or attribute quickly, and hence helps in parsing. 751 "[entry]" means the permissions apply to the entire object. This could 752 mean actions such as delete the object, or add a child object. When 753 used in subtreeACI, the specified permissions (on the entry set of 754 permissions are legal here - see the ABNF) apply to each entry in the 755 subtree. 757 "[all]" means the permission set applies to all attributes of the entry. 758 When used in subtreeACI, "[all]" applies to all attributes of each entry 759 in the subtree. 761 If the keyword "[all]" and another attribute are both specified within 762 an ACI, the more specific permission set for the attribute overrides the 763 less specific permission set for "[all]". 765 4.2.3 Subjects and Associated Authentication 767 The following subjects are defined and MUST be supported: 769 - authzId, defined per [AuthMeth] 771 - group, defined as the distinguished name of a groupOfNames or 772 groupOfUniqueNames entry 774 - role, asserts a subject's organizational position and entitlement 775 to perform the operations appropriate to that organizational 776 position. It is implementation defined how the association between 777 authorization id and the role dn is made. 779 - subtree, defined as some distinguished name of a non-leaf node in 780 the DIT 782 - ipAddress, in IPv6 text format [IPV6] 784 - dnsName, a domain name or a wildcarded (left-most name or most 785 specific part) domain name (see ABNF) 787 - public, defined as public access 788 - this, defined as the user whose name matches that of the entry 789 being accessed 791 Other parties MAY define other subjects. It is the responsibility of 792 those parties to provide the definition. Adding new subjects may 793 inhibit interoperability. 795 A subject may be qualified by the level of authentication required for 796 access to a given attribute(s) or entry. authnLevel defines the minimum 797 requestor authentication level required for a given ACI. For a 798 requestor's authentication level to exceed a minimum requirement, the 799 requestor's level must meet or exceed that specified in the ACI. 801 The authentication levels defined, in increasing order of 802 authentication, are: 804 - none - no name and no password, or name but no password 806 - weak - authentication mechanisms that are prone to both passive and 807 active attacks [ATTACK]; for example, simple authentication (name 808 and password) 810 - limited - authentication mechanisms that protect against passive 811 attacks but may be prone to active attacks; for example, DIGEST-MD5 813 - strong - authentication mechanisms that protect against both 814 passive and active attacks; for example, Kerberos with per- 815 authentication or PKI authentication 817 The authnLevel applies to a subject as follows: 819 - If the ACI is a grant, then the authnLevel applies if the subject 820 is authenticated at or above that level. 822 - If the ACI is a deny, then the authnLevel applies to that subject 823 if authenticated at that level AND to all other subjects 824 authenticated with levels below that. 826 Authentication level is always specified in an ACI. For grant, this 827 means that you are granted access if you can prove your authentication 828 via a strong authentication mechanism, such as a digital signature. For 829 deny, the meaning of this is "you are denied access if you are Mr. X and 830 you can prove it with a digital signature". If you are not Mr. X you 831 are not denied access only if you can prove it (authenticate yourself) 832 with a digital signature. In other words, everyone who does not 833 authenticate with a digital signature is denied access. Everyone who 834 authenticates with a digital signature is allowed access except Mr. X. 836 A recommended categorization of authentication mechanisms per 837 authentication level may be offered separately. For each mechanism 838 categorized in the recommendations, implementations SHOULD NOT assign a 839 higher authentication level, but MAY assign a lower authentication 840 level. For mechanisms not covered by the recommendation, the 841 implementation SHOULD specify a conservative level. Implementations 842 SHOULD provide a means for the directory administrator to disable and/or 843 lower the authentication level associated with a mechanism. 845 Two interesting subjects not explicitly included, but can be composed 846 using subject and authnLevel are anonymous and authenticated. 848 - anonymous: authnLevel=none + anySubject(public) 850 - authenticated: authnLevel=weak + anySubject(public) 852 4.3 Access Control Decision Making 854 The ultimate goal of the Access Control Model is to define the way in 855 which an LDAP server determines an access control decision for a given 856 requested LDAP operation. In fact, a requestor may require several 857 individual permissions in order to be authorized to carry out an LDAP 858 operation and we define these in section 5. In this section we 859 introduce the concepts and algorithm that allow the server to decide if 860 a requestor has an individual permission on an individual resource. The 861 concepts we require are firstly, the parameters which must be provided 862 in order for the Access Control Decision Algorithm to determine whether 863 the access is allowed or not. Secondly, we define precisely when a 864 given ACI value will be involved in a given access control decision. 865 Thirdly, this model defines some precedence rules which the Algorithm 866 will use when dealing with more than one ACI value. Finally, we can 867 define the Access Control Decision Algorithm which will determine the 868 access decision. Throughout, we use the ABNF, when we need to refer to 869 portions of individual ACI values. 871 4.3.1 The Parameters to the Access Decision Algorithm 873 The decision algorithm answers the question "Does the specified 874 requestor have the specified permission on the specified resource?" The 875 resource may be an entry (as for the Delete operation) or it may be an 876 attribute within an entry (as for the Modify operation) so we 877 characterize the resource like this: (targetEntry, targetAttribute 878 OPTIONAL). 880 The requestor is identified primarily by his authorization ID (which may 881 be omitted if the requestor has bound anonymously), but also includes 882 other context information about the requestor so it is represented like 883 this: (authzId OPTIONAL, ipAddress, dnsName, authnLevel). 885 The permission is one of the valid permissions defined by the model. 887 So, the parameters to the Access Control Decision Algorithm, which we 888 will refer to collectively as "the decision parameters" are: 890 - resource: (targetEntry, targetAttribute OPTIONAL) 892 - permission: permissionParameter 894 - requestorSubject: (authzId OPTIONAL, ipAddress, dnsName, 895 authnLevel) 897 If permissionParameter is an attribute-level parameter then 898 targetAttribute must be specified; if it is an entry-level permission 899 then targetAttribute is ignored. 901 The output is either "Access Allowed" or "Access Denied". 903 4.3.2 Applicability Rules 905 The applicability rules define whether a given ACI value, or portions of 906 it, apply to some given decision parameters. 908 4.3.2.1 Applicability Rules for Scope Types 910 These rules determine whether a specific ACI applies to the targetEntry 911 part of the decision parameters. 913 - If the ACI in question is an entryACI, then ACI applies to the 914 resource if the ACI is an attribute of the entry targetEntry. 916 - If the ACI in question is a subtreeACI, then ACI applies to the 917 resource if targetEntry is part of the subtree defined by the entry 918 containing the ACI. 920 4.3.2.2 Applicability Rules for Permissions 922 If permissionParameter is an entry-level permission, then the ACI in 923 question applies if permissionParameter is mentioned in the permissions 924 list of the ACI. 926 If permissionParameter is an attribute-level permission, then the ACI in 927 question applies if permissionParameter is mentioned in the permissions 928 list and the ACI's attribute list applies to the target attribute per 929 "Applicability Rules for Attributes". 931 Note that for an ACI which contains both grant and deny permissions 932 lists, the grant permission list may not be available for the purposes 933 of this applicability rule--see point 3 in the "Applicability Rules for 934 Subjects". 936 4.3.2.3 Applicability Rules for Attributes 938 If an attribute is not specified as part of the resource, then this rule 939 does not apply. If an attribute is specified, then the ACI in question 940 applies if its attribute list is [all] or if targetAttribute is 941 explicitly mentioned in the ACI's attribute list. 943 In the case where targetAttribute is an attribute type with options 944 (e.g. sn;lang-en;lang-uk), it is applicable if the ACI's attribute list 945 mentions a less specific form of targetAttribute. For example, if the 946 list contained "sn;lang-en", then that list applies to the attribute 947 "sn;lang-en;lang-uk", but not the attribute "sn". 949 4.3.2.4 Applicability Rules for Subjects 951 Call the subject portion of the ACI in question aciSubject. Then to 952 determine if aciSubject applies to requestorSubject we apply the 953 following rules: 955 1. The ACI in question is a grant ACI. Then the ACI applies if both 956 the context and pureSubject portions of aciSubject apply, as 957 defined in "Applicability Rules for Context" and "Applicability 958 Rules for pureSubject" below. 960 2. The ACI in question is a deny ACI. There are three possibilities: 962 a. The pureSubject part applies (according to "Applicability 963 Rules for pureSubject"). Then the ACI applies to 964 requestorSubject. 966 b. The pureSubject part does not apply. Then the ACI applies 967 to any requestorSubject with an authnLevel less than the 968 authnLevel of the ACI. 970 c. Otherwise the ACI does not apply. 972 3. The ACI in question is both a deny and grant ACI. There are three 973 possibilities: 975 a. aciSubject applies when evaluated as a grant ACI (per 1 976 above). Both the grant permissions and deny permissions of 977 the ACI are available for the purpose of the "Applicability 978 Rules for Attributes and Permissions". 980 b. aciSubject does not apply as a grant ACI but does apply as a 981 deny ACI (per 2 above). The deny permissions of the ACI are 982 available for the purpose of the "Applicability Rules for 983 Attributes" and the "Applicability Rules for Permissions". 985 c. aciSubject does not apply when evaluated as either a grant 986 ACI or a deny ACI. The ACI does not apply to 987 requestorSubject. 989 Note: the deny behavior with authnLevel deserves explication. In the 990 case where an ACI denies access to a given subject with a given 991 authnLevel, then naturally it will deny access to that given subject 992 authenticated at authnLevel or above. Similarly, another user 993 authenticated at authnLevel or above, to which the pureSubject part does 994 not apply, will not be denied those rights by that ACI. 996 The interesting case is a user authenticated at a lower level than 997 authnLevel. For such a user the ACM takes the view that as that user 998 has not proved to the system, to a sufficient degree of confidence, that 999 the pureSubject portion does not apply to him, then to be safe, he will 1000 be denied those rights. 1002 So if you deny access to a particular authzId with authnLevel of "none", 1003 then that authzId will be denied access at any authentication level, but 1004 it will not affect any other requestors. On the other hand, if you deny 1005 access to a particular authzId with an authnLevel of "strong", then that 1006 will deny access to that user when authenticated strongly AND deny 1007 access to ANY users authenticated with lower authentication levels. 1009 4.3.2.5 Applicability Rules for pureSubject 1011 If aciSubject is of type anySubject, then it applies to 1012 requestorSubject. 1014 If aciSubject is of type machineSubject, then if the ipAddress or dns 1015 name from requestorSubject matches the ipAddress or dns name range in 1016 aciSubject, then the ACI applies to requestorSubject if it is a deny ACI 1017 or the deny part of a grant/deny ACI. A grant ACI (or the grant part of 1018 a grant/deny ACI) never applies if the subject is ipAddress: or dns:. 1019 The note at the end of the "Precedence of Subjects within a Scope" 1020 explains the reasoning behind this rule. 1022 If the aciSubject is of type idBasedSubject, then it applies according 1023 to the definition in "Applicability Rules for idBasedSubject". 1025 4.3.2.6 Applicability Rules for Context 1027 The context of aciSubject applies to requestorSubject if authnLevel from 1028 requestorSubject is greater than or equal to the authnLevel specified in 1029 the context part of aciSubject. 1031 4.3.2.7 Applicability Rules for idBasedSubject 1033 If idBasedSubject is of type thisSubject, then it applies to 1034 requestorSubject if authzId from requestorSubject is of type "dn" and is 1035 equal to the DN of the resource. 1037 If idBasedSubject is of type oneSubject, then it applies to 1038 requestorSubject if authzId from requestorSubject is equal to the 1039 authzId specified in aciSubject. 1041 If idBasedSubject is of type setOfSubjects, then it applies to 1042 requestorSubject if authzId from requestorSubject is defined to be in 1043 the set specified in aciSubject (i.e. is in that group, role or 1044 subtree). The "Precedence of Subjects within a Scope" includes rules 1045 for determining membership in a setOfSubjects. 1047 4.3.3 Precedence Rules 1049 The precedence rules allow the Access Control Decision Algorithm to 1050 determine which ACI values should take precedence over others. 1052 4.3.3.1 Precedence of Scope Types 1054 1. Entry 1056 2. Subtree 1058 4.3.3.2 Precedence of Position in the DIT 1060 For a given subject DN (including authentication level) and target DN, 1061 subtreeACI lower in the tree take precedence over those higher in the 1062 tree. 1064 4.3.3.3 Precedence of Subjects within a Scope 1066 1. ipAddress or dns in a deny ACI or the deny part of a grant/deny 1067 ACI 1069 2. authzId distinguished name ("authzId-dn:") or authzId userid 1070 ("authzId-u:") 1072 3. this 1074 4. role 1076 If the DN of a role or a group appears in a role (e.g. appears as 1077 a value of roleOccupant in an organizationalRole), it is 1078 recursively expanded. For determination of precedence, the 1079 resulting expanded collection of names is considered to have come 1080 from a role regardless of the original source. 1082 5. group 1084 If the DN of a role or a group appears in a group, it is 1085 recursively expanded. For determination of precedence, the 1086 resulting expanded collection of names is considered to have come 1087 from a group regardless of the original source. 1089 6. subtree 1091 Subtrees may contain groups and/or roles. They should be 1092 recursively expanded. For determination of precedence, members of 1093 groups or occupants of roles that apply because (after recursive 1094 expansion) the group or role is contained in a subtree are 1095 considered to have come from the subtree regardless of the 1096 original source. 1098 7. public 1100 The precedence of ipAddress and DNS names are treated specially, and 1101 depend on the type of ACI involved. Typical situations are: 1103 - If an ACL says to grant on the basis of IP address but deny on the 1104 basis of some other attribute (username, group, etc....), then the 1105 behavior we want is "deny". Rationale: the user is prohibited from 1106 access, regardless of where he's sitting. 1108 - If an ACL says to deny on the basis of IP address but grant on the 1109 basis of some other attribute (username, group, etc....), then the 1110 behavior we want is also "deny". Rationale: the user is allowed 1111 access, but not from where he's sitting. 1113 In addition, a grant to an ipAddress with no other applicable ACI is 1114 very dangerous from a security point of view, since it would grant 1115 permissions to ANY user who has access to the machine with the given 1116 address. Thus ipAddress and dns subjects can be used only to deny 1117 permission, not to grant them. The "Applicability Rules for 1118 pureSubject" enforce this. 1120 4.3.3.4 Precedence of Attribute Specifications 1122 Access controls specifying "[all]" attributes are of lower precedence 1123 than specific lists. 1125 4.3.3.5 Precedence of grant/deny 1127 Deny takes precedence over grant. 1129 4.3.3.6 Default 1131 Deny is the default when there is no access control information or when 1132 evaluation of the access control information yields no result that 1133 allows the requester access. 1135 4.3.4 Access Control Decision Algorithm 1137 The Access Control Decision Algorithm takes as input the decision 1138 parameters defined above and produces a grant or a deny decision. 1140 In the case where we are interested in the permission set for a set of 1141 entries and attributes (as in the case of evaluating the effective 1142 rights in section 9), then we must apply the algorithm for each 1143 entry/attribute and permission pair we are interested in. Naturally 1144 implementers are free to implement any algorithm which produces the same 1145 decision given the same input and ACI values in a DIT. 1147 The algorithm has two phases. First, all the potentially applicable ACI 1148 values are sorted into an ordered list of sets of ACI values of the same 1149 precedence. Then this list is scanned in order to find the set of ACIs 1150 which will determine the access decision. 1152 Phase 1: Order the potentially applicable ACI values 1154 1. Determine all the entryACI and subtreeACI values that apply to 1155 targetEntry, according to the "Applicability Rules for Scope 1156 Types". 1158 2. Sort these ACIs into a list of sets of ACIs of equal precedence, 1159 according to the "Precedence of Scope Types" and "Precedence of 1160 Position in the DIT" rules. 1162 3. Determine which of the collected ACI values from step 1 apply to 1163 requestorSubject using the "Applicability Rules for Subjects". 1164 All the ACI values which do not apply to this subject are 1165 discarded. 1167 4. The list of sets is sorted according to subject type from the 1168 "Precedence of Subjects within a Scope" rules. 1170 5. Now we split the list into two separate lists keeping the same 1171 relative ordering of sets--one list has the sets that just contain 1172 ACI values that refer to entry-level permissions and the other has 1173 the sets that just contain ACI values that refer to attribute- 1174 level permissions. 1176 6. Each set in the attribute-level list of sets is further divided 1177 into a list of sets of equal precedence according to "Precedence 1178 of Attributes Specification". 1180 Note: At this point we have two lists of sets of ACI values, one dealing 1181 with entry-level permissions the other dealing with attribute-level 1182 permissions. The lists have been sorted according to Scope, Position, 1183 Subject and (for the attribute-level list) Attribute Specification 1184 precedence rules. 1186 Phase 2: Scan the lists to determine the access decision: 1188 1. If permissionParameter is an entry-level permission (so that the 1189 optional targetAttribute field is not specified), then scan the 1190 list of entry-level sets in order. The first set in the list that 1191 contains an ACI that applies to permissionParameter (as defined in 1192 the "Applicability Rules for Permissions" rules) determines the 1193 access decision--if an ACI in the set grants permissionParameter 1194 and no other denies it, then access is granted, otherwise access 1195 is denied. 1197 2. If permissionParameter is an attribute-level permission then scan 1198 the list of attribute-level sets in order. The first set in the 1199 list that contains an ACI that applies to permissionParameter AND 1200 applies to targetAttribute (as defined in the "Applicability Rules 1201 for Attributes" and "Applicability Rules for Permissions") 1202 determines the access decision--if an ACI in the set grants 1203 permissionParameter and no other denies it, then access is 1204 granted, otherwise access is denied. 1206 4.3.5 Precedence/Inheritance Access Decision Example 1207 The examples in this section refer to the following directory tree: 1209 dc=com 1210 | 1211 +--------+---------------+ 1212 | | 1213 dc=tivoli dc=sun 1214 | | 1215 cn=ellen cn=rob 1217 The ACI at dc=com: 1219 1. subtreeACI:grant:rsc#[all]#authnLevel:none:public: 1220 2. subtreeACI:deny:rsc#userPassword,subtreeACI,entryACI,salary# 1221 authnLevel:none:public: 1222 3. subtreeACI:grant:bvt#[entry]#authnLevel:none:public: 1223 4. subtreeACI:grant:rscmow#[all]#authnLevel:strong: 1224 authzID-dn:cn=rob,dc=sun,dc=com 1225 5. subtreeACI:grant:bvtugeinad#[entry]#authnLevel:strong: 1226 authzID-dn:cn=rob,dc=sun,dc=com 1228 The ACI at dc=tivoli,dc=com: 1230 6. subtreeACI:grant:rsc;deny:mow#[all]#authnLevel:strong: 1231 authzID-dn:cn=rob,dc=sun,dc=com 1232 7. subtreeACI:deny:einad#[entry]#authnLevel:strong: 1233 authzID-dn:cn=rob,dc=sun,dc=com 1235 The ACI at cn=ellen,dc=tivoli,dc=com 1237 8. entryACI:grant:wo#[all]#authnLevel:strong: 1238 authz-ID-dn:cn=ellen,dc=tivoli,dc=com 1239 9. entryACI: deny: wo#entryACI,subtreeACI,salary#authnLevel:strong: 1240 authz-ID-dn:cn=ellen,dc=tivoli,dc=com 1242 Example #1 1244 subject: ("cn=rob,dc=sun,dc=com", ipaddress, dns name, strong): 1245 resource: ("cn=ellen,dc=tivoli,dc=com", salary) 1246 permission: "w" 1248 Phase 1: Find all applicable ACI based on the Applicability of Scope 1249 Types. 1251 {1, 2, 3, 4, 5, 6, 7, 8, 9} 1253 Sort by Precedence of Scope Type and Precedence of Position in 1254 DIT: 1256 {8, 9}, {6, 7}, {1, 2, 3, 4, 5} 1258 Determine which ACI are applicable based on the Subject: 1260 {6, 7}, {1, 2, 3, 4, 5} 1262 Sort by Precedence of Subjects within Scope: 1264 {6, 7}, {4, 5}, {1, 2, 3} 1266 Separate permissions applicable to entry and those applicable 1267 to attributes: 1269 Entry: {7}, {5}, {3} 1270 Attr: {6}, {4}, {1, 2} 1272 Sort the permissions applicable to attributes by precedence of 1273 attribute specification: 1275 Entry: {7}, {5}, {3} 1276 Attr: {6}, {4}, {2}, {1} 1278 Phase 2: Since "w" is an attribute permission, look at the Attr list. 1279 ACI 6 in the first sub-list mentions "w" and salary (via 1280 [all]) so this set defines the access--which is deny. 1282 Example #2 1284 subject: ("cn=rob,dc=sun,dc=com", ipaddress, dns name, limited): 1285 resource: ("cn=ellen,dc=tivoli,dc=com", salary) 1286 permission: "w" 1288 Phase 1: First the ACIs are ordered into the following sets whose 1289 subject matches the subject tuple: 1291 Entry: {7}, {3} 1292 Attr: {6}, {2}, {1} 1294 Phase 2: For ACI 6 in the first set, which matched the subject because 1295 of the deny portion and limited < strong, the permissions 1296 available are "mow". So, this ACI applies to "w" and salary 1297 (via [all]) and the access is "deny". 1299 Example #3 1301 subject: ("cn=rob,dc=sun,dc=com", ipaddress, dns name, limited): 1302 resource: ("cn=ellen,dc=tivoli,dc=com", salary) 1303 permission: "r" 1305 Phase 1: First the ACIs are ordered into the following sets whose 1306 subject matches the subject tuple: 1308 Entry: {7}, {3} 1309 Attr: {6}, {2}, {1} 1311 Phase 2: As the grant portion of ACI 6 is not active, the first set 1312 that contains an ACI that applies to "r" and salary is {2}. 1313 As 2 denies access, access is denied. 1315 Example #4 1317 subject: ("cn=rob,dc=sun,dc=com", ipaddress, dns name, limited): 1318 resource: ("cn=ellen,dc=tivoli,dc=com", cn) 1319 permission: "r" 1321 Phase 1: First the ACIs are ordered into the following sets whose 1322 subject matches the subject tuple: 1324 Entry: {7}, {3} 1325 Attr: {6}, {2}, {1} 1327 Phase 2: As the grant portion of ACI 6 is not active, the first set 1328 that contains an ACI that applies to "r" and cn is {1}. As 1 1329 grants access, access is granted. 1331 5. Required Permissions for each LDAP Operation 1333 This section defines the required permissions for each LDAP operation. 1334 Even if these requirements are satisfied, the server may refuse to carry 1335 out the operation due to other implementation specific security 1336 considerations. For example, a server may refuse to modify an entry 1337 because the database where that entry resides is in read only mode. 1338 Another example might be that although LDAP access control has been 1339 specified on the userPassword attribute a server may refuse 1340 modifications due to some server specific policy governing access to 1341 passwords. 1343 Here, we specify the rights required by a user when performing an LDAP 1344 operation in terms of the LDAP permissions specified above. Recall that 1345 "a, d, e, i, n, b, v, t, u" are permissions that apply to entries as a 1346 whole while permissions "r, s, p, w, o, c, m, g" apply to attributes 1347 within entries. 1349 Required permissions for LDAP extended operations and LDAP controls 1350 SHOULD be defined along with their specifications. These requirements 1351 could be expressed in terms of this model, for example by requiring one 1352 of the existing permissions on some particular entry or attribute. This 1353 version of the LDAP access control model does not offer any mechanism to 1354 extend the permission set or aci syntax to accommodate extended 1355 operations or controls. 1357 For the following, assume that the authorization identity of the user 1358 doing the operation is authzId. 1360 5.1 Bind Operation 1362 This model does not require any permissions to allow a bind operation to 1363 proceed. 1365 5.2 Search Operation 1367 Recall that the parameters of the Search operation per RFC 2251 [LDAPv3] 1368 Section 4.5 are: 1370 SearchRequest ::= [APPLICATION 3] SEQUENCE { 1371 baseObject LDAPDN, 1372 scope ENUMERATED { 1373 baseObject (0), 1374 singleLevel (1), 1375 wholeSubtree (2) }, 1376 derefAliases ENUMERATED { 1377 neverDerefAliases (0), 1378 derefInSearching (1), 1379 derefFindingBaseObj (2), 1380 derefAlways (3) }, 1381 sizeLimit INTEGER (0 .. maxInt), 1382 timeLimit INTEGER (0 .. maxInt), 1383 typesOnly BOOLEAN, 1384 filter Filter, 1385 attributes AttributeDescriptionList } 1387 Suppose a server is processing a search request from user authzId with 1388 parameters as above and is processing the entry with dn candidateDN to 1389 decide if it may be returned or not. 1391 Then the permissions required by authzId that need to be evaluated are 1392 as follows: 1394 1. permission "b" to the entry candidateDN if the entry is in the 1395 scope of the search but is not the base entry. 1397 If this permission is not granted then the dn candidateDN MUST NOT 1398 be returned nor any attribute type nor attribute value from this 1399 entry. 1401 Note: the "b" permission is included to allow different browsing 1402 or discovery rights to be assigned to different classes of users. 1404 2. permission "v" to the entry candidateDN 1406 If this permission is not granted then the dn candidateDN MUST NOT 1407 be returned nor any attribute type nor attribute value from this 1408 entry. 1410 Note A: The "v" permission is the entry level read permission. 1411 This is included as it is useful to have one simple permission 1412 (not dependent on scope or aliasing) that protects all the 1413 components of an entry; the dn and the attributes. 1415 Note B: Disclosing the full distinguished name of an entry will 1416 inevitiably reveal the names of its ancestors. This issue is 1417 discussed in detail below. 1419 3. permission "p" or "s" to each attribute appearing in a search 1420 filter presence test during the evaluation of the search filter. 1421 permission "s" is required on attributes appearing in non-presence 1422 tests (see RFC2254, section 3: equalityMatch, substrings, 1423 greaterOrEqual, lessOrEqual, present, approxMatch, 1424 extensibleMatch) during the evaluation of the search filter. 1426 The above statement covers the case where the attributes are being 1427 evaluated as part of an extensibleMatch (RFC 2251 section 4.5.1) 1428 which appears in the filter. In the case where the dnAttributes 1429 field of the extensibleMatch is true (and so the filter test is 1430 applied to the naming attributes in the dn of the entry) then we 1431 do not require any access checks to the attributes of the dn as 1432 access to these is taken to be granted by the "v" permission, 1433 which has already been required above. 1435 If there is an attribute in a filter element to which the required 1436 permission is not granted then that filter element evaluates to 1437 "Undefined" of the three-valued-logic of X.511(93). 1439 Note: The motivation for the "p" permission is that if you have 1440 full filter rights on an attribute then in some cases that could 1441 be operationally the same as having read permission i.e. you could 1442 quickly determine the attribute value, and this may not be 1443 desirable. For example, if the type of the attribute was integer 1444 then with full filter permissions you could quickly determine the 1445 value by doing a sequence of binary chop style searches using ">" 1446 and "<". Whereas, with just the presence test ability, you would 1447 not have right to do those kind of searches, but you would be able 1448 to test for the presence of the attribute. 1450 4. permission "r" to each attribute in the attribute list 1451 AttributeDescriptionList (or all attributes in the entry 1452 candidateDN if AttributeDescriptionList is *) whose type and/or 1453 value will be returned. 1455 Note A: The presence of an attribute in an entry is only ever 1456 volunteered by the server if "r" permission is granted to it, 1457 though a user may infer the presence of an attribute with "s" or 1458 "p" permission by using a presence test on that attribute in the 1459 search filter. 1461 Note B: Although both "r" and "s" permissions will typically be 1462 granted to attributes we keep both permissions as there are cases 1463 where the distinction is useful. A reverse telephone lookup is an 1464 example of granting "r" but not "s" permission. 1466 5. permission "t" to the entry candidateDN 1468 If this permission is not granted then the dn candidateDN MUST NOT 1469 be returned. If the server knows of an alias for the entry, this 1470 alias may be returned instead. If no alias name is available then 1471 the entry candidateDN MUST be omitted from the search results. 1473 Note: Disclosing the full distinguished name of an entry will 1474 inevitiably reveal the names of its ancestors. This issue is 1475 discussed in detail below. 1477 6. Disclose on error for the Search operation 1479 If there is no entry in the scope of the search which satisfies 1480 item 1 (browse right on the candidate entry) and item 2 (read 1481 level permission on the entry) and item 3 (right to use the filter 1482 on that entry) then the "u" permission on the base entry must be 1483 evaluated. If "u" (disclose on error) is not granted to the base 1484 entry then the operation MUST fail with a "no such object error" 1485 and the matchedDN of the LDAPResult MUST be set to "". If "u" is 1486 granted to the baseObject then the empty set of results is 1487 returned. 1489 Note: the point here is that if you do not have the right to 1490 discover at least one entry in the scope of the search then the 1491 disclose on error mechanism is there to prevent you discovering 1492 the base entry of the search. The "t" permission is not 1493 considered here as it is not conceptually a permission involved in 1494 the discovery of entries but rather in how they are returned (dn 1495 vs. alias). 1497 5.2.1 Protecting the naming attributes of DNs 1499 Protecting the naming attributes in an entry's dn presents a problem for 1500 access control. The issue is that if access is granted to the dn of a 1501 given entry, then via the naming attributes this dn contains, access is 1502 also also granted to attribute values in other entries. In addition, 1503 knowledge about the existence of ancestor entries of a given entry is 1504 also disclosed by the entry's dn. 1506 It could be argued that there should be consistency in the ability of a 1507 given requestor to see attribute values in the dn of an entry and his 1508 ability to see those attributes in the entry where they actually reside. 1509 Similarly, it could be argued that there should be consistency in the 1510 ability of a requestor to see an entry and his ability to see its 1511 ancestor entries. 1513 The main reason we do not require such cross checking of permissions is 1514 because of the extra work it entails for the server. There is a trade 1515 off between the consistency this cross checking guarantees and the work 1516 it takes to do that cross checking. 1518 For LDAP servers the trade off has been to go in favor of speed. In 1519 addition there are some other points which mitigate these kind of 1520 inconsistencies. Firstly, it appears to be difficult to produce a real 1521 world example where they really cause a problem. Secondly there are 1522 other methods of hiding DNs (and hence protecting the naming attribute 1523 and ancestor information they contain) which are outside the scope of 1524 access control, for example aliasing and LDAP proxying. 1526 5.3 Modify Operation 1528 Recall that the parameters of the Modify operation per RFC2251 [LDAPv3] 1529 Section 4.6 are: 1531 ModifyRequest ::= [APPLICATION 6] SEQUENCE { 1532 object LDAPDN, 1533 modification SEQUENCE OF SEQUENCE { 1534 operation ENUMERATED { 1535 add (0), 1536 delete (1), 1537 replace (2) }, 1538 modification AttributeTypeAndValues } } 1540 AttributeTypeAndValues ::= SEQUENCE { 1541 type AttributeDescription, 1542 vals SET OF AttributeValue } 1544 Then the permissions required by authzId that need to be evaluated are 1545 as follows: 1547 1. permission "w" to each attribute being added to object 1549 If this permission is not granted to such an attribute, then the 1550 operation MUST fail. 1552 2. permission "o" to each attribute for which a value is being 1553 deleted from object 1555 If this permission is not granted to such an attribute, then the 1556 operation MUST fail. 1558 3. permissions "o" and "w" to each attribute being replaced in object 1560 If each of these items is satisfied then the operation is allowed 1561 by the access control model. If one of these items is not 1562 satisfied, then the operation MUST fail. In this case, if "u" 1563 (discloseOnError) is granted to object, then the usual error codes 1564 (such as noSuchObject, attributeOrValueExists, noSuchAttribute and 1565 insufficientAccess) and matchedDN value may be returned; if "u" is 1566 not granted to object then nosuchObject MUST be returned and 1567 matchedDN set to "". 1569 5.4 Add Operation 1571 Recall that the parameters of the Add operation per RFC2251 [LDAPv3] 1572 Section 4.7 are: 1574 AddRequest ::= [APPLICATION 8] SEQUENCE { 1575 entry LDAPDN, 1576 attributes AttributeList } 1578 AttributeList ::= SEQUENCE OF SEQUENCE { 1579 type AttributeDescription, 1580 vals SET OF AttributeValue } 1582 Then the permissions required by authzId that need to be evaluated are 1583 as follows: 1585 1. permission "a" to the parent of entry 1587 The access rights required for the creation of a root entry in the 1588 Directory are beyond the scope of this document. They will be 1589 vendor specific. 1591 2. permission "m" to the parent of entry for each attribute being 1592 added to entry 1594 If each of these items is satisfied then the operation is allowed by the 1595 access control model. If one of these items is not satisfied, then the 1596 operation MUST fail. In this case, if "u" (discloseOnError) is granted 1597 to the parent of entry, then the usual error codes (such as 1598 noSuchObject, entryAlreadyExists, and insufficientAccess) and matchedDN 1599 value may be returned; if "u" is not granted to the parent of entry, 1600 then nosuchObject MUST be returned and matchedDN set to "". 1602 Note A: We require "m" permission to each attribute to prevent an entry 1603 from acquiring "unintended" rights (via group or role membership), to 1604 stop a "rogue" ACI being added that would prevent even admins deleting 1605 the entry, and for general consistency with the MODIFY operation. 1607 5.5 Delete Operation 1609 Recall that the parameters of the Delete operation per RFC2251 [LDAPv3] 1610 Section 4.10 are: 1612 DelRequest ::= [APPLICATION 10] LDAPDN 1614 Then the permissions required by authzId that need to be evaluated are 1615 as follows: 1617 1. permission "d" to the entry in the Delete request 1619 If each of these items is satisfied then the operation is allowed by the 1620 access control model. If one of these items is not satisfied, then the 1621 operation MUST fail. In this case, if "u" (discloseOnError) is granted 1622 to the entry to be deleted, then the usual error codes (such as 1623 noSuchObject, and insufficientAccess) and matchedDN value may be 1624 returned; if "u" is not granted to object then nosuchObject MUST be 1625 returned and matchedDN set to "". 1627 Note: One could also require the "o" permission to be granted to allow 1628 the operation to proceed, but customer experience has shown that the 1629 requirement of the additional permission is not useful nor expected, and 1630 X.500 requires only the "d" permission. 1632 5.6 Modify DN Operation 1634 Recall that the parameters of the Modify DN operation per RFC2251 1635 [LDAPv3] Section 4.6 are: 1637 ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { 1638 entry LDAPDN, 1639 newrdn RelativeLDAPDN, 1640 deleteoldrdn BOOLEAN, 1641 newSuperior [0] LDAPDN OPTIONAL } 1643 The variants of the ModifyDN operation are listed below. Combinations 1644 of the write, obliterate, import, export and renameDN permissions are 1645 needed for each variant. 1647 1. Rename an entry by moving the conceptual RDN flag between two 1648 existing attribute values, without altering any attribute values 1649 at all. Permissions needed are renameDN. 1651 2. Rename an entry by adding a new attribute value. Permissions 1652 needed are renameDN and write. 1654 3. Rename an entry using an existing attribute value and delete the 1655 current attribute value. Permissions needed are renameDN and 1656 obliterate. 1658 4. Rename an entry adding a new attribute value and deleting the 1659 current attribute value. Permissions needed are renameDN, write, 1660 and obliterate. 1662 5. Move an entry to a new place in the DIT, keeping its existing RDN 1663 as is. Permissions needed are import and export. 1665 6. Move an entry to a new place coupled with 1. above Permissions 1666 needed are import, export, and renameDN. 1668 7. Move coupled with 2. above. Permissions needed are import, 1669 export, renameDN, and write. 1671 8. Move coupled with 3. above. Permissions needed are import, 1672 export, renameDN, and obliterate. 1674 9. Move coupled with 4. above. Permissions needed are import, 1675 export, renameDN, write, and obliterate. 1677 For a given case, if the required permissions are granted, then the 1678 operation is allowed by the access control model. If, for a given case, 1679 the required permissions are not granted, then the operation MUST fail. 1680 If the access control failure is due to a missing attribute or entry 1681 permission on entry, then if "u" (discloseOnError) is granted to entry, 1682 then the usual error codes (such as noSuchObject, attributeOrValueExists 1683 and insufficientAccess) and matchedDN value may be returned; if "u" is 1684 not granted to entry then nosuchObject MUST be returned and matchedDN 1685 set to "". Similar logic applies if the access control failure was due 1686 to a missing permission on newSuperior. 1688 5.7 Compare Operation 1690 Recall that the parameters of the Compare operation per RFC2251 [LDAPv3] 1691 Section 4.10 are: 1693 CompareRequest ::= [APPLICATION 14] SEQUENCE { 1694 entry LDAPDN, 1695 ava AttributeValueAssertion } 1697 Then the permissions required by authzId that need to be evaluated are 1698 as follows: 1700 1. permission "c" to the attribute in entry on which the comparison 1701 is being made. 1703 If each of these items is satisfied then the operation is allowed by the 1704 access control model. If one of these items is not satisfied, then the 1705 operation MUST fail. In this case, if "u" (discloseOnError) is granted 1706 to entry, then the usual error codes (such as noSuchObject, and 1707 insufficientAccess) and matchedDN value may be returned; if "u" is not 1708 granted to entry then nosuchObject MUST be returned and matchedDN set to 1709 "". 1711 5.8 Abandon Operation 1713 Recall that the parameters of the Abandon operation per RFC2251 [LDAPv3] 1714 Section 4.6 are: 1716 AbandonRequest ::= [APPLICATION 16] MessageID 1718 authzId always has the right to send an Abandon Operation for an 1719 operation he previously initiated. 1721 5.9 Extended Operation 1723 Recall that the parameters of the Extended operation per RFC2251 1724 [LDA{v3] Section 4.12 are: 1726 ExtendedRequest ::= [APPLICATION 23] SEQUENCE { 1727 requestName [0] LDAPOID, 1728 requestValue [1] OCTET STRING OPTIONAL } 1730 The access required for an Extended Operation is beyond the scope of 1731 this document. The required access will normally be defined by the 1732 implementer of the extended request. 1734 6. Required Permissions for Handling Aliases and References 1736 Use of aliases and referrals are part of LDAPv3. However, neither is 1737 particularly well-defined. Alias objects and attributes are defined in 1738 RFC 2256 as derived from X.500, but LDAPv3 does not explicitly define 1739 their semantics or behavior. X.500 does define alias semantics and 1740 behavior with respect to access control; we define its behavior in 1741 LDAPv3 based on the X.511 (1993) [X511], section 7.11.1. Referrals and 1742 knowledge information are still under design in LDAPv3; they are defined 1743 in X.500, however, X.500 does not specify their semantics and behavior 1744 with respect to access control. We define their semantics and behavior 1745 in LDAPv3 in terms that should be independent of the future LDAPv3 1746 definition of referrals and knowledge information. 1748 6.1 ACI Distribution 1750 Currently there is no LDAP standard defining how to distribute directory 1751 data between LDAP servers. Consequently this model cannot fully specify 1752 the behavior of the Access Control Model in a distributed environment. 1753 The case of distribution via referrals is treated in the "Referrals" 1754 section below. In the case of chaining (where one LDAP server forwards a 1755 request to another on behalf of a client) then it is server specific how 1756 the access control model behaves in this environment. Similarly it is 1757 server specific how the server determines whether the chaining of an 1758 operation is permitted in the first place. For example, the 1759 implementation may choose to regard the local naming context and the 1760 remote subordinate naming context as separate Access Control Specific 1761 Areas, or it may regard the DIT as one Access Control Specific Area and 1762 implement mechanisms to propagate access control information between the 1763 two servers. The behavior of the Access Control Model in distributed 1764 environments such as these is beyond the scope of this model. 1766 6.2 Aliases 1768 There are two things to protect with respect to aliases: the real name 1769 of the aliased object and the location of the server holding it. 1771 If alias de-referencing is required in the process of locating a target 1772 entry, no specific permissions are necessary for alias de-referencing to 1773 take place. Access control is enforced at the object pointed to by the 1774 alias. 1776 If alias de-referencing would result in a continuationReference (e.g. 1777 from a search operation), then browse permission is required to the 1778 alias entry and read permission is required to the attribute. Requiring 1779 these permission closes the hole of discovery. 1781 6.3 Referrals 1783 If a referral is to be followed, no specific permissions are necessary 1784 for the ldap client to follow the referral. Access control is enforced 1785 at the referenced object. If a referral is returned, then browse is 1786 required on the entry and read permission is required to the attribute 1787 containing the referral (we cannot name this attribute exactly today 1788 because there are no RFCs on this). If the server implements a default 1789 referral, then no special permissions are required to read and return 1790 that referral. Requiring these permissions closes the hole of 1791 discovery. In the default case, it is assumed that a default referral 1792 is public. 1794 7. Controlling Access to Access Control Information 1796 The entryACI and subtreeACI attributes are used to specify control for 1797 who has permission to set/change access control information (entryACI 1798 and subtreeACI). The entryACI and subtreeACI attributes/OIDs are just 1799 another attribute described with set of rights and permissions, and 1800 subject as a value of the entryACI and subtreeACI attributes. (See the 1801 example in the "ACI Examples" section). 1803 If the policy for controlling the entryACI and subtreeACI attributes are 1804 not specified for any object in the tree, behavior is implementation 1805 defined. For instance, if no object anywhere in the tree defines the 1806 access for entryACI/subtreeACI within the entryACI/subtreeACI 1807 attributes, then the server could simply assert that the 'root DN' is 1808 considered the policy owner (controller for controlling access control) 1809 for all objects. 1811 8. ACI Examples 1813 Note that in the examples, the form "OID." refers to the OID 1814 in dotted decimal form for the attribute . This shorthand 1815 notation is used only for the examples. In implementation, the dotted 1816 decimal form of the OID is used. 1818 8.1 Attribute Definition 1820 The following examples show the access required to control access to the 1821 entryACI and subtreeACI attributes. The first example shows controlling 1822 the access control on an individual entry and its attributes. The 1823 second example shows controlling the access control on a subtree. The 1824 authnLevel is set so that a reasonably secure form of authentication is 1825 required, since changing ACI has significant security consequences. 1827 entryACI: grant:rwo# 1828 OID.entryACI#authnLevel:limited:role:cn=aciAdmin 1830 subtreeACI: grant:rwo# 1831 OID.subtreeACI#authnLevel:limited:role:cn=aciAdmin 1833 The next example shows a subtreeACI attribute where a group "cn=Dept 1834 XYZ, c=US" is being given permissions to read, search, and compare 1835 attribute attr1. The permission applies to the entire subtree below the 1836 node containing this ACI. 1838 subtreeACI: grant;rsc# 1839 OID.attr1#authnLevel:weak:group:cn=Dept XYZ,c=US 1841 The next example shows an ACI attribute where a role 1842 "cn=SysAdmins,o=Company" is being given permissions to browseDN, 1843 viewEntry, and returnDN for objects below this node. The role is also 1844 being given permission to read, search, and compare to attribute attr2 1845 and read, search, compare, write, obliterate to attr3. The permissions 1846 apply to the entire subtree below the node containing this ACI. 1848 subtreeACI: grant:bvt# 1849 [entry]#authnLevel:weak:role:cn=SysAdmins,o=Company 1851 subtreeACI: grant:rsc# 1852 OID.attr2#authnLevel:weak:role:cn=SysAdmins,o=Company 1854 subtreeACI: grant:rscwo# 1855 OID.attr3#authnLevel:weak:role:cn=SysAdmins,o=Company 1857 8.2 Modifying the entryACI and subtreeACI Values 1859 Modify-Replace works as defined in the ldap operation modify. If the 1860 attribute value does not exist, create the value. If the attribute does 1861 exist, replace the value. If the entryACI/subtreeACI value is replaced, 1862 all entryACI/subtreeACI values are replaced. To modify the 1863 entryACI/subtreeACI attributes requires you to have 'w' and 'o' 1864 permission on the entryACI/subtreeACI attribute (recall that a value of 1865 entryACI/subtreeACI specifies entryACI/subtreeACI so one can control 1866 access to the entryACI/subtreeACI attribute). The examples in this 1867 section assume that you have access to control entryACI/subtreeACI. 1869 A given subtreeACI for an entry: 1871 subtreeACI: deny:rw#[all]#authnLevel:weak:group:cn=Dept ABC 1873 subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ 1875 perform the following change: 1877 dn: cn=someEntry 1878 changetype: modify 1879 replace: subtreeACI 1880 subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept LMN 1882 The resulting ACI is: 1884 subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept LMN 1886 ( subtreeACI values for Dept XYZ and ABC are lost through the replace ) 1888 During an ldapmodify-add, if the ACI does not exist, the create the ACI 1889 with the specific entryACI/subtreeACI value(s). If the ACI does exist, 1890 then add the specified values to the given entryACI/subtreeACI. For 1891 example a given ACI: 1893 subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ 1895 with a modification: 1897 dn: cn=someEntry 1898 changetype: modify 1899 add: subtreeACI 1900 subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ 1902 would yield an multi-valued ACI of: 1904 subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ 1906 subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ 1908 To delete a particular ACI value, use the regular ldapmodify - delete 1909 syntax 1911 Given an ACI of: 1913 subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ 1914 subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ 1916 dn: cn = some Entry 1917 changetype: modify 1918 delete: subtreeACI 1919 subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ 1921 would yield a remaining ACI on the server of 1923 subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ 1925 The attributes which are defined for access control interchange may be 1926 used in all LDAP operations. 1928 Within the ldapmodify-delete operation, the entire acl may be deleted by 1929 specifying 1931 dn: cn = some Entry 1932 changetype: modify 1933 delete: entryACI 1935 dn: cn = some Entry 1936 changetype: modify 1937 delete: subtreeACI 1939 In this case, the entry would then inherit its ACI from other nodes in 1940 the tree depending on the inheritance model. 1942 Similarly, if all values of entryACI and subtreeACI are deleted, then 1943 the access control information for that entry is defined by the 1944 inheritance model. 1946 8.3 Evaluation 1948 These examples assume that the ACI entries listed in each example are 1949 the only ACI which applies to the entry in question; if backing-store 1950 ACI also exists, the effective policy may be different from that listed 1951 in each example. 1953 Assume cn=jsmith is a member of group cn=G1. Assume cn=jsmith is a 1954 member of group cn=G2. 1956 Example #1 1958 dn: o=XYZ, c=US 1959 subtreeACI: grant:r#attr2 1960 #authnLevel:weak:group:cn=G1,ou=ABC,o=XYZ,c=US 1961 subtreeACI: grant:w#attr2 1962 #authnLevel:weak:group:cn=G2,ou=ABC,o=XYZ,c=US 1964 What rights does cn=jsmith have to attr2 of o=XYZ,c=US? Read-write (rw) 1965 access; ACI is combined because both subjects (group) have same 1966 precedence. 1968 Example #2 1970 dn: o=XYZ, c=US 1971 subtreeACI: grant:rw#OID.attr3 1972 #authnLevel:weak:group:cn=G1,ou=ABC,o=XYZ,c=US 1973 subtreeACI: 1974 deny:w#OID.attr3#authnLevel:weak:group:cn=G2,ou=ABC,o=XYZ,c=US 1976 What rights does cn=jsmith have to attr3 of o=XYZ, c=US? Read access; 1977 write is denied (deny has precedence over grant). 1979 Example #3 1981 dn: o=XYZ, c=US 1982 subtreeACI: grant:m#OID.attr5 1983 #authnLevel:weak:authzID-dn:cn=jsmith,o=ABC,c=US 1984 subtreeACI: grant:m#OID.cn 1985 #authnLevel:weak:authzID-dn:cn=jsmith,o=ABC,c=US 1986 subtreeACI: grant:m#OID.sn 1987 #authnLevel:weak:authzID-dn:cn=jsmith,o=ABC,c=US 1988 subtreeACI: grant:a#[entry] 1989 #authnLevel:weak:authzID-dn:#cn=jsmith,o=ABC,c=US 1991 What rights does cn=jsmith have to o=XYZ, c=US? Make(m) on attributes 1992 attr5, cn, and sn and Add(a) on the entry. These are the minimal yet 1993 sufficient permissions to create a new object, cn=New, o=XYZ, c=US with 1994 values for the attr5, cn, and sn attributes. This example illustrates 1995 how the "m" permission can be used to limit the attributes that can be 1996 created on a new entry. 1998 Example #4 2000 dn: c=US 2001 subtreeACI: grant:m#[all]#authnLevel:weak:subtree:c=US 2002 dn: o=XYZ, c=US 2003 subtreeACI: grant:a#[entry]# 2004 authnLevel:weak:authzID-dn:cn=jsmith,o=ABC,c=US 2006 What rights does cn=jsmith have to o=XYZ, c=US? Make(m) on attributes 2007 all attributes and Add(a) on the entry. These are sufficient permissions 2008 to create a new object, cn=New, o=XYZ, c=US with values for any desired 2009 attributes. For administrators who do not wish to limit the attributes 2010 that can be created on new entries, this example shows how a single 2011 ldapACI at the top of the domain solves the problem. 2013 Example #5 2015 dn: dc=com,dc=demo 2016 subtreeACI: grant:rw#description;lang-en#authnLevel:weak:authzID-dn: 2017 cn=rvh,dc=att,dc=com 2018 subtreeACI: grant:rw#description;lang-en,description;lang-fr# 2019 authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com 2021 In this example, cn=rvh,dc=att,dc=com has "rw" access to the English- 2022 language "description" attributes of entries under dc=com,dc=demo. 2023 cn=rob,dc=sun,dc=com has "rw" rights to both English- and French- 2024 language "description" attributes. The example demonstrates that 2025 "Attribute Descriptions", not just "Attribute Types", can be used in the 2026 "attr" field of an ACI. See [LangCode] for more information on the 2027 attribute options used here. 2029 8.4 ModDN 2031 There are many different actions that can happen when the modDN command 2032 are used. The following illustrates the permissions needed in order to 2033 execute each scenario. For all examples, we will assume the role 2034 cn=Admins is working with the following entry: 2036 dn: cn=personA, o=Company 2037 cn: personA 2038 cn: FirstName 2039 sn: LastName 2040 objectclass: person 2042 Example #1 2044 Perform a modRDN only, using an existing attribute value. In this case, 2045 we perform a modRDN and rename cn=personA, o=Company to cn=FirstName, 2046 o=Company. The entryACI value for this entry must give the cn=Admin role 2047 rename permission on the entry. 2049 entryACI: grant:n#[entry]#authnLevel:weak:role:cn=Admin 2051 Example #2 2053 We wanted to perform a ModRDN and add a new attribute value. In this 2054 case we are renaming cn=personA, o=Company to cn=newFirstName, 2055 o=Company. The entryACI value must give the cn=Admin role rename 2056 permission on the entry and w permission on the cn attribute. 2058 entryACI: grant:n#[entry]#authnLevel:weak:role:cn=Admin 2059 entryACI: grant:w#cn#authnLevel:weak:role:cn=Admin 2061 Example #3 2063 Perform a modRDN, using an existing attribute, but delete the old RDN 2064 value. Here, we perform a modRDN and rename cn=personA, o=Company to 2065 cn=FirstName, o=Company and set the deleteOldRdn flag to true. The 2066 cn=Admin role must have permission to rename the entry, and to delete a 2067 cn attribute value ( i.e. 'o' ). 2069 entryACI: grant:n#[entry]#authnLevel:weak:role:cn=Admin 2070 entryACI: grant:o#OID.cn#authnLevel:weak:role:cn=Admin 2072 Example #4 2074 Perform a modRDN, using an new cn attribute value (cn=newFirstName), and 2075 delete the old RDN value (cn=personA). Here, we perform a modRDN and 2076 rename cn=personA, o=Company to cn=newFirstName, o=Company and set the 2077 deleteOldRdn flag to true. The cn=Admin role must have permission to 2078 rename the entry, and to delete and write the cn attribute value. 2080 entryACI: grant:n#[entry]#authnLevel:weak:role:cn=Admin 2081 entryACI: grant:w,o#OID.cn#authnLevel:weak:role:cn=Admin 2083 Example #5 2085 We want to change the entry's location in the DIT ( modDN ) and keep the 2086 same RDN Value. In this case we are moving cn=personA, o=Company to 2087 cn=personA, o=CompanyB. The cn=Admin role must have export permission on 2088 the original entry, and import permission on the new superior object ( 2089 the new parent ). The cn=personA, o=Company entryACI is: 2091 entryACI: grant:e#[entry]#authnLevel:weak:role:cn=Admin 2093 and the o=CompanyB entryACI is: 2095 entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin 2097 Example #6 2099 We want to change the entry's location in the DIT ( modDN ) and change 2100 the RDN Value to an existing attribute value. In this case we are moving 2101 cn=personA, o=Company to cn=FirstName, o=CompanyB. The cn=Admin role 2102 must have rename and export permission on the original entry, and import 2103 permission on the new superior object ( the new parent ). The 2104 cn=personA, o=Company entryACI is: 2106 entryACI: grant:en#[entry]#authnLevel:weak:role:cn=Admin 2108 and the o=CompanyB entryACI is: 2110 entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin 2112 Example #7 2114 We want to change the entry's location in the DIT ( modDN ) and change 2115 the RDN Value to a new attribute value. In this case we are moving 2116 cn=personA, o=Company to cn=newFirstName, o=CompanyB. The cn=Admin role 2117 must have rename and export permission on the original entry, write 2118 permission on the naming attribute ( cn) and import permission on the 2119 new superior object ( the new parent ). The cn=personA, o=Company 2120 entryACI is: 2122 entryACI: grant:en#[entry]#authnLevel:weak:role:cn=Admin 2123 entryACI: grant:w#OID.cn#authnLevel:weak:role:cn=Admin 2125 and the o=CompanyB entryACI is: 2127 entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin 2129 Example #8 2131 We want to change the entry's location in the DIT ( modDN ) and change 2132 the RDN Value to an existing attribute value, and delete the old RDN 2133 value. In this case we are moving cn=personA, o=Company to 2134 cn=FirstName, o=CompanyB and deleting the attribute value personA. The 2135 cn=Admin role must have rename and export permission on the original 2136 entry, delete ('o') permission on the naming attribute (cn) and import 2137 permission on the new superior object (the new parent). The cn=personA, 2138 o=Company entryACI is: 2140 entryACI: grant:en#[entry]#authnLevel:weak:role:cn=Admin 2141 entryACI: grant:o#cn#authnLevel:weak:role:cn=Admin 2143 and the o=CompanyB entryACI is: 2145 entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin 2147 Example #9 2149 We want to change the entry's location in the DIT ( modDN ) and change 2150 the RDN Value to a new attribute value, and delete the old RDN value. 2151 In this case we are moving cn=personA, o=Company to cn=newFirstName, 2152 o=CompanyB and deleting the attribute value personA. The cn=Admin role 2153 must have rename and export permission on the original entry, write 2154 ('w'), and delete ('o') permission on the naming attribute (cn) and 2155 import permission on the new superior object ( the new parent ). The 2156 cn=personA, o=Company entryACI is: 2158 entryACI: grant:en#[entry]#authnLevel:weak:role:cn=Admin 2159 entryACI: grant:wo#OID.cn#authnLevel:weak:role:cn=Admin 2161 and the o=CompanyB entryACI is: 2163 entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin 2165 8.5 Interaction Among ACI 2167 These examples show how ACI in different parts of the tree interact. 2168 Examples with varying authnLevel are given in the next section. 2170 The examples refer to this fragment of a directory tree: 2172 dc=com 2173 | 2174 +--------+---------------+ 2175 | | 2176 dc=tivoli dc=sun 2177 | | 2178 cn=ellen cn=rob 2180 Example #1 2182 If the ACI is as follows: 2184 at dc=com: subtreeACI:grant:rw#[all]#authnLevel:weak: 2185 authzID-dn:cn=rob,dc=sun,dc=com 2186 at dc=tivoli,dc=com: subtreeACI:grant:r#[all]#authnLevel:weak: 2187 authzID-dn:cn=rob,dc=sun,dc=com 2189 Then the effective rights of cn=rob,dc=sun,dc=com to all the attributes 2190 of object cn=ellen,dc=tivoli,dc=com are "rw". The ACI at 2191 dc=tivoli,dc=com is redundant. 2193 Example #2 2195 If the ACI is as follows: 2197 at dc=com: subtreeACI:grant:r#[all]# authnLevel:weak: 2198 authzID-dn:cn=rob,dc=sun,dc=com 2199 at dc=tivoli,dc=com: subtreeACI:grant:w#OID.uid#authnLevel:weak: 2200 authzID-dn:cn=rob,dc=sun,dc=com 2202 Then cn=rob,dc=sun,dc=com has effective rights of "r" to all the 2203 attributes of object cn=ellen,dc=tivoli,dc=com, and effective rights of 2204 "rw" to the uid attribute of object cn=ellen,dc=tivoli,dc=com. Also, 2205 cn=rob,dc=sun,dc=com has effective rights of "r" to all attributes of 2206 object cn=rob,cn=sun,cn=com. 2208 Example #3 2210 If the ACI is as follows: 2212 at dc=com: subtreeACI:grant:rw#[all]#authnLevel:weak: 2213 authzID-dn:cn=rob,dc=sun,dc=com 2214 at dc=tivoli,dc=com: subtreeACI:deny:w#[all]#authnLevel:weak: 2215 authzID-dn:cn=rob,dc=sun,dc=com 2217 Then cn=rob,dc=sun,dc=com has effective rights of "r" (but not "w") to 2218 all the attributes of object cn=ellen,dc=tivoli,dc=com and has effective 2219 rights of "rw" to all attributes of objects cn=rob,dc=sun,dc=com. 2221 Example #4 2223 If the ACI is as follows: 2225 at dc=com: subtreeACI:grant:r#OID.uid#authnLevel:weak: 2226 authzID-dn:cn=rob,dc=sun,dc=com 2227 at dc=tivoli,dc=com: subtreeACI:grant:w#OID.sn#authnLevel:weak: 2228 authzID-dn:cn=rob,dc=sun,dc=com 2230 Then cn=rob,dc=sun,dc=com has effective rights of "r" to the uid 2231 attribute and "w" to the sn attribute of object 2232 cn=ellen,dc=tivoli,dc=com. 2234 Example #5 2236 If the ACI is as follows: 2238 at dc=com: subtreeACI:grant:r#OID.uid#authnLevel:weak: 2239 authzID-dn:cn=rob,dc=sun,dc=com 2240 at cn=rob,dc=sun,dc=com: entryACI:grant:rw#[all]#authnLevel:weak: 2241 this: 2243 Then cn=rob,dc=sun,dc=com has effective rights of "rw" to all attributes 2244 of object cn=rob,dc=sun,dc=com. 2246 Example #6 2248 If the ACI is as follows: 2250 at dc=com: subtreeACI:grant:rw#uid#authnLevel:weak: 2251 authzID-dn:cn=rob,dc=sun,dc=com 2252 at dc=tivoli,dc=com: subtreeACI:deny:w#uid#authnLevel:weak: 2253 subtree:dc=sun,dc=com 2255 Then cn=rob,dc=sun,dc=com has rights of "r" to the uid attribute of 2256 object cn=ellen,dc=tivoli,dc=com. While checking the "w" permission, 2257 the subtreeACI at dc=tivoli,dc=com is lower in the tree than the 2258 subtreeACI at dc=com, so it takes precedence at Step 1. 2260 Example #7 2262 If the ACI is as follows: 2264 at dc=com: subtreeACI:grant:rw#OID.uid#authnLevel:weak: 2265 authzID-dn:cn=rob,dc=sun,dc=com 2266 at dc=com: subtreeACI:deny:w#OID.uid#authnLevel:weak: 2267 subtree:dc=sun,dc=com 2269 Then cn=rob,dc=sun,dc=com has rights of "rw" to the uid attribute of 2270 object cn=ellen,dc=tivoli,dc=com. While checking the "w" permission, 2271 the two subtreeACI are at the same level in the tree (step 1) and the 2272 Subject Type dn-dn has precedence over Subject Type subtree (step 2), so 2273 the first ACI has precedence over the second. 2275 Example #8 2277 If the ACI is as follows: 2279 at dc=com: subtreeACI:grant:rw#OID.uid#authnLevel:weak: 2280 subtree:dc=sun,dc=com 2281 at dc=com: subtreeACI:deny:w#OID.uid#authnLevel:weak:subtree:dc=com 2283 Then cn=rob,dc=sun,dc=com has rights of "r" to the uid attribute of 2284 object cn=ellen,dc=tivoli,dc=com. While checking the "w" permission, 2285 the two subtreeACI are at the same level in the tree (step 1) and they 2286 have the same Subject Type (step 2), so the precedence of deny over 2287 grant (step 5) is the deciding factor. 2289 Example #9 2291 If the ACI is as follows: 2293 at dc=com: subtreeACI:grant:rw#OID.uid#authnLevel:weak: 2294 subtree:dc=sun,dc=com 2295 at dc=com: subtreeACI:deny:w#[all]#authnLevel:weak:subtree:dc=com 2297 Then cn=rob,dc=sun,dc=com has rights of "rw" to the uid attribute of 2298 object cn=ellen,dc=tivoli,dc=com. While checking the "w" permission, 2299 the two subtreeACI are at the same level in the tree (step 1) and they 2300 have the same Subject Type (step 2), so the precedence of a specific 2301 attribute list over "[all]" (step 4) is the deciding factor. 2303 8.6 Use of ipAddress in ACI 2305 Using the tree fragment from Section 8.5: 2307 Example #1 2309 If the ACI is as follows: 2311 at dc=com: subtreeACI: deny:adeinbvtug#[entry]# 2312 authnLevel:strong:ipAddress:10.0.0.0-10.255.255.255 2313 subtreeACI: deny:rwospcm#[all]# 2314 authnLevel:strong:ipAddress:10.0.0.0-10.255.255.255 2315 subtreeACI: grant:rscp#[all]#authnLevel:none:public: 2316 subtreeACI: grant:btv#[entry]#authnLevel:none:public: 2318 Then any user regardless of the strength of their authentication is 2319 denied all permissions if they happen to be connecting from an IP 2320 address in the 10-net. If they connect from any other address, they 2321 have "rscp" permissions for all attributes and "btv" permissions for all 2322 entries in the dc=com subtree. 2324 Example #2 2326 If the ACI is as follows: 2328 at dc=com: subtreeACI: grant:adeinbvtug#[entry]# 2329 authnLevel:weak:ipAddress:10.0.0.0-10.255.255.255 2330 subtreeACI: grant:rspwocm#[all]# 2331 authnLevel:weak:ipAddress:10.0.0.0-10.255.255.255 2333 It will have no effect. While it might seem that it would grant total 2334 access to any user bound from an address in 10-net, the special rules 2335 governing ipAddress and dns as subjects make them useful only for deny 2336 ACI, not for grants. This was done because the effects of a mistaken 2337 grant to an IP address range or wildcarded DNS name could be extremely 2338 serious. 2340 An (insane) administrator who really wants to grant total access to 2341 anyone on 10-net would have to specify: 2343 at dc=com: subtreeACI: grant:adeinbvtug#[entry]#authnLevel:weak:public: 2344 subtreeACI: deny:adeinbvtug#[entry]# 2345 authnLevel:strong:ipAddress:0.0.0.0-9.255.255.255, 2346 11.0.0.0-255.255.255.255 2347 subtreeACI: grant:rspwocm#[all]#authnLevel:weak:public: 2348 subtreeACI: deny:rspwocm#[all]# 2349 authnLevel:strong:ipAddress:0.0.0.0-9.255.255.255, 2350 11.0.0.0-255.255.255.255 2352 This ACI depends on the fact that a "deny" works on the stated 2353 authnLevel and all lower authnLevels while a "grant" works on the stated 2354 level and all higher authnLevels. 2356 8.7 Use of authnLevel in ACI 2358 Using the tree fragment from Section 8.5: 2360 Example #1 2362 If the ACI is as follows: 2364 at dc=com: subtreeACI:grant:rw#OID.sn#authnLevel:strong: 2365 authzID-dn:cn=rob,dc=sun,dc=com 2366 at dc=tivoli,dc=com: subtreeACI:grant:r#OID.sn#authnLevel:limited: 2367 authzID-dn:cn=rob,dc=sun,dc=com 2369 Then cn=rob,dc=sun,dc=com has effective rights of "rw" to the sn 2370 attribute of object cn=ellen,dc=tivoli,dc=com if the BIND for this 2371 session used strong authentication. If the BIND for this session used 2372 limited authentication, cn=rob,dc=sun,dc=com has effective rights of "r" 2373 to the sn attribute of object cn=ellen,dc=tivoli,dc=com. If the BIND 2374 for this session used weak or no authentication, cn=rob,dc=sun,dc=com 2375 has no rights to object cn=ellen,dc=tivoli,dc=com. 2377 Example #2 2379 If the ACI is as follows: 2381 at dc=com: subtreeACI: grant:rw#sn#authnLevel:limited: 2382 subtree:dc=sun,dc=com 2383 at dc=tivoli,dc=com: subtreeACI: grant:c;deny:w#sn#authnLevel:strong: 2384 authzID-dn:cn=rob,dc=sun,dc=com 2386 Then cn=rob,dc=sun,dc=com has effective rights of "rc" to the sn 2387 attribute of object cn=ellen,dc=tivoli,dc=com if the BIND for this 2388 session used strong authentication. The "r" permission comes from the 2389 fact that the grant part of the first ACI applies to BINDs at or above 2390 the "limited" level. If the BIND for this session used limited 2391 authentication, cn=rob,dc=sun,dc=com has "r" rights to the sn attribute 2392 of object cn=ellen,dc=tivoli,dc=com. The deny part of the second ACI 2393 applies to cases where the authnLevel is less than "strong", so it 2394 overrides the grant of "w" permission in the first ACI. If the BIND for 2395 this session is at the weak or none authnLevel, the user has no 2396 permissions. 2398 Example #3 2400 If the ACI is as follows: 2402 at dc=com: subtreeACI:grant:rs#sn#authnLevel:none:public 2403 at dc=com: subtreeACI:grant:w#sn#authnLevel:strong: 2404 subtree:cn=rob,dc=sun,dc=com 2406 Then cn=rob,dc=sun,dc=com has effective rights of "rsw" to the sn 2407 attribute of object cn=ellen,dc=tivoli,dc=com if the BIND for this 2408 session used strong authentication and effective rights "rs" if the BIND 2409 for this session used any other form of authentication. The grant in 2410 the first ACI applies to BINDs at the "none" level and above, so it 2411 applies to any authnLevel. 2413 Example #4 2415 If the ACI is as follows: 2417 at root: subtreeACI:grant:ps#[all]#authnLevel:none:public: 2418 subtreeACI:grant:cr#[all]#authnLevel:weak:subtree: 2420 Then any user including the anonymous user (no name supplied to BIND) 2421 has "ps" permissions to any entry on the server, and any user with an ID 2422 on the server ("subtree:" specifies any DN in the subtree under root) 2423 who has bound using "weak" or better authentication has "pscr" 2424 permissions. 2426 Example #5 2428 If the ACI is as follows: 2430 at dc=com: subtreeACI:grant:rw#[all]#authnLevel:limited: 2431 cn=ellen,dc=tivoli,dc=com 2432 at dc=tivoli,dc=com: subtreeACI:deny:w#[all]#authnLevel:strong: 2433 cn=rob,dc=sun,dc=com 2435 Then if bound at the strong authnLevel, user cn=ellen,dc=tivoli,dc=com 2436 has permissions "rw" to all the attributes of the object 2437 cn=ellen,dc=tivoli,dc=com, and permissions "rw" to all the attributes of 2438 the object cn=rob,dc=sun,dc=com. But if bound at the limited 2439 authnLevel, user cn=ellen,dc=tivoli,dc=com has permissions "r" to all 2440 the attributes of the object cn=ellen,dc=tivoli,dc=com, and permissions 2441 "rw" to all the attributes of the object cn=rob,dc=sun,dc=com. 2443 This is a consequence of the way that "deny" is processed with respect 2444 to authnLevel. Since cn=rob,dc=sun,dc=com is denied "w" permission when 2445 authenticating at the "strong" authnLevel, ALL users are denied "w" 2446 permission when bound at any weaker level (see the rules for authnLevel 2447 in "Subjects and Associated Authentication"). 2449 9. GetEffectiveRights Control 2451 The access control information controls provide a way to manipulate 2452 access control information in conjunction with a LDAP operation. One 2453 LDAP control is defined. This control allows access control information 2454 to be retrieved. The control is: 2456 GetEffectiveRights - obtain the effective rights for a given 2457 directory entry(s) for a given subject during a ldap_search 2458 operation 2460 The purpose of the getEffectiveRights control is to allow an 2461 administrator or application to query the server about the rights of 2462 another user of the directory. This is important as it would allow the 2463 administrator to verify the access control policy for a given subject. 2464 Or it would allow an application for example, to propose to a user the 2465 attributes which he has the right to modify or see in a given entry. 2467 9.1 Request Control 2469 This control may only be included in the ldap_search message as part of 2470 the controls field of the LDAPMessage, as defined in Section 2471 4.1.12 of [LDAPv3]. 2473 The controlType is set to . The criticality MAY be 2474 either TRUE or FALSE (where absent is also equivalent to FALSE) at the 2475 client's option. The controlValue is an OCTET STRING, whose value is 2476 the BER encoding of a value of the following SEQUENCE: 2478 GetEffectiveRightsRequest ::= SEQUENCE{ 2479 gerSubject [0] GERSubject 2480 } 2482 GERSubject ::= SEQUENCE { 2483 gerOneSubject [0] OneSubject -- from 4.1.2 , OPTIONAL 2484 germachineSubject [1] GERMachineSubject, 2485 gerAuthnLEvel [2] AuthnLevel, -- from 4.1.2 2486 } 2488 GERMachineSubject ::= SEQUENCE{ 2489 gerOneIPAddress [0] IPAddress, -- from 4.1.2 2490 gerOneDNSName [1] DomainName -- from 4.1.2 2491 } 2493 The getEffectiveRightsRequest specifies a subject, gerSubject, about 2494 whom access control information is being requested. The control asks 2495 the server to evaluate and return the entry level rights possessed by 2496 the gerSubject for each entry that is returned in the search results, 2497 and for each returned or specifically requested attribute. The server 2498 will use the Access Decision Algorithm from section 4.3 to determine the 2499 requested effective rights; it will be seen that the parameters defining 2500 the subject in the Access Decision algorithm ((dn OPTIONAL, ipAddress, 2501 dnsName, authnLevel)) are all present in this control. 2503 9.2 Response Control 2505 This control is included in the ldap_search_response message as part of 2506 the controls field of the LDAPMessage, as defined in Section 4.1.12 of 2507 [LDAPv3]. 2509 The controlType is set to . There is no need to set 2510 the criticality on the response. The controlValue is an OCTET STRING, 2511 whose value is the BER encoding of a value of the following SEQUENCE: 2513 GetEffectiveRightsResponse ::= { 2514 result ENUMERATED { 2515 success (0), 2516 operationsError (1), 2517 unavailableCriticalExtension (12), 2518 noSuchAttribute (16), 2519 undefinedAttributeType (17), 2520 invalidAttributeSyntax (21), 2521 insufficientRights (50), 2522 unavailable (52), 2523 unwillingToPerform (53), 2524 other (80) 2525 } 2526 } 2528 The effective rights returned are returned with each entry returned by 2529 the search result. The control response for ldap_search is: 2531 PartialEffectiveRightsList ::= SEQUENCE { 2532 entryLevelRights [0] EffectiveRights, 2533 attributeLevelRights [1] AttributeLevelRights 2534 } 2536 EffectiveRights ::= CHOICE { 2537 rights [0] Permissions -- from 4.1.2, 2538 noRights [1] NULL, 2539 errorEvaluatingRights [2] GerError 2540 } 2542 GerError ::= ENUMERATED 2543 {generalError(0),insufficientAccess(1)} 2545 AttributeLevelRights ::= SEQUENCE OF { 2546 attr [0] SEQUENCE OF Attribute, 2547 rights [1] EffectiveRights 2548 } 2550 For a given entry, the control response entryLevelRights field contains 2551 the entry level effective rights that gerSubject has on that entry. The 2552 attributeLevelRights field contains a list of attributes and the 2553 effective rights that gerSubject has for each of those attributes. The 2554 list of attributes consists of those attributes returned as part of the 2555 search operation plus any explicitly requested attributes that were not 2556 returned. An attribute explicitly requested in the search request might 2557 not be returned because the attribute is not in the entry, but we may 2558 still be interested in the effective rights on it, for example to 2559 determine if gerSubject could add that attribute to the entry. 2561 The control returns the permissions that gerSubject has on a given entry 2562 and its attributes. In order to determine whether these permissions 2563 suffice to allow gerSubject to perform a given LDAP operation on the 2564 entry, the requestor will determine if these permissions satisfy the 2565 required permissions for that LDAP operation, as defined in section 5. 2567 Note that in the case where gerSubject does not have a particular 2568 permission then this control does not allow the requestor to determine 2569 whether that is because the permission was not granted to gerSubject or 2570 whether it was because this permission has been explicitly denied. 2572 The required permissions to see the effective rights of a subject on an 2573 entry and its attributes are specified in 9.3. 2575 If gerSubject has the same rights to a set of attributes in that entry 2576 then the server may group the attributes together in a list. 2578 Although this extends the search operation, there are no 2579 incompatibilities between versions. LDAPv2 cannot send a control, hence 2580 the above structure cannot be returned to a LDAPv2 client. A LDAPv3 2581 client cannot send this request to a LDAPv2 server. A LDAPv3 server not 2582 supporting this control cannot return the additional data. 2584 9.3 Access control for the Get Effective Rights Control 2586 In the presence of the get effective rights control, the access controls 2587 applied to the search operation use the requestor's authorization 2588 identity. 2590 For a given entry returned in the search results then in order to see 2591 the effective rights of any subject for this entry and its attributes 2592 the requestor requires: 2594 1. "g" permission on the entry. 2596 If 1. is not satisfied then the "insufficientAccess" error is returned 2597 for the entryLevelRights of that entry and for each of the rights in the 2598 AttributeLevelRights list. 2600 Note A: the set of entries and attributes that are returned are those 2601 visible to the requestor, not the gerSubject. This means that it is 2602 possible that if gerSubject could see an entry that the requestor could 2603 not then it is impossible for the requestor, using the 2604 getEffectiveRights control, to retrieve the effective rights of 2605 gerSubject on that entry. However, the idea here is that the requestor 2606 will typically be a powerful administrator whose access rights will be a 2607 superset of those of other users. 2609 Note B: once a given subject has the "g" permission on a given entry 2610 then he has the right to see the effective rights of _any_ subject on 2611 that entry. It might be useful to have a way to restrict the set of 2612 subjects whose effective rights can be retrieved but that complicates 2613 the model in that, for the "g" permission only, we no longer have a 2614 target/subject type structure but rather a target/subject/otherSubject 2615 structure. Here, we choose the simpler model rather than this extra 2616 functionality. 2618 9.4 Get Effective Rights example 2620 Suppose we have a DIT with the entries and access controls as described 2621 in the following LDIF example: 2623 o=sun.com 2624 objectclass: top 2625 objectclass: organization 2626 o: sun.com 2627 subtreeACI: grant:rsc#[all]#authnLevel:none:public: 2628 subtreeACI: deny:rsc#[userPassword,subtreeACI, 2629 entryACI,salary]#authnLevel:none:public: 2630 subtreeACI: grant:bvt#[entry]#authnLevel:none:public: 2631 subtreeACI: grant:g#[entry]#authnLevel:limited:this: 2632 subtreeACI: grant:worsc#[all]#authnLevel:limited:this: 2633 subtreeACI: deny: wo[entryACI, subtreeACI, salary]#this 2634 subtreeACI: grant:rscmo,w#[all]#authnLevel:strong:group: 2635 cn=adminGroup,ou=Groups,o=sun.com 2636 subtreeACI: grant:bvtugeinad#[entry]#authnLevel:strong 2637 group: cn=adminGroup,ou=Groups,o=sun.com 2639 cn=admin,o=sun.com 2640 objectclass: top 2641 objectclass: person 2642 cn: admin 2643 sn: admin 2644 userPassword: secret 2645 salary: 10000 2647 ou=Groups,o=sun.com 2648 objectclass: top 2649 objectclass: organizationalUnit 2650 ou: Groups 2652 cn=adminGroup,ou=Groups,o=sun.com 2653 objectclass: top 2654 objectclass: groupOfUniqueNames 2655 uniquemember: cn=admin,o=sun.com 2657 ou=Eng,o=sun.com 2658 objectclass: top 2659 objectclass: organizationalUnit 2660 ou: Eng 2662 cn=Joe Engineer,ou=Eng,o=sun.com 2663 objectclass: top 2664 objectclass: person 2665 cn: Joe Engineer 2666 sn: Engineer 2667 userPassword: secret 2668 salary: 10000 2670 ou=Sales,o=sun.com 2671 objectclass: top 2672 objectclass: organizationalUnit 2674 cn=Joe Sales,ou=Sales,o=sun.com 2675 objectclass: top 2676 objectclass: person 2677 cn: Joe Sales 2678 sn: Sales 2679 userPassword: secret 2680 salary: 100000000000 2682 The access control policy in this DIT policy may be described as 2683 follows: 2685 1. anonymous users have full read, search, and compare rights to the 2686 whole DIT, except for the important attributes userPassword, 2687 subtreeACI, entryACI, and salary. 2689 2. Any user bound with a limited authentication level can modify any 2690 attributes in his own entry, except subtreeACI, entryACI and 2691 salary. 2693 3. Any user can read all attributes in his own entry. 2695 4. Any user bound with a limited authentication level can retrieve 2696 the effective rights on his own entry (including userPassword, 2697 salary, entryACI and subtreeACI). 2699 5. users, bound with a strong authentication level, in the 2700 cn=adminGroup,ou=Groups,o=sun.com group have full rights in the 2701 whole DIT. 2703 Then here are some examples of requests to get the effective rights and 2704 the responses: 2706 Example 1. Suppose we issue a search authenticated to level strong as 2707 "cn=admin,o=sun.com" (who is in the group 2708 cn=adminGroup,ou=Groups,o=sun.com), with base "o=sun.com", search filter 2709 "objectclass=*", requested attributes "* entryACI", with the 2710 getEffectiveRights control subject set to "cn=Joe 2711 Sales,ou=Sales,o=sun.com" and the MachineSubject specifying the 2712 ipAddress and dnsName of the client machine and the authnLevel set to 2713 limited. 2715 Then the search result and effective rights we see are: 2717 o=sun.com 2718 objectclass: top 2719 objectclass: organization 2720 o: sun.com 2722 entryLevelRights: bvt 2723 attributeLevelRights: objectclass,o: rsc,entryACI: none 2724 --- 2725 cn=admin,o=sun.com 2726 objectclass: top 2727 objectclass: person 2728 cn: admin 2729 sn: admin 2730 userPassword: secret 2731 salary: 10000 2733 entryLevelRights: bvt 2734 attributeLevelRights: objectclass,cn,sn: rsc 2735 userPassword,salary,entryACI: none 2736 --- 2737 ou=Groups,o=sun.com 2738 objectclass: top 2739 objectclass: organizationalUnit 2740 ou: Groups 2742 entryLevelRights: bvt 2743 attributeLevelRights: objectclass,ou: rsc,entryACI: none 2744 --- 2745 ou=Eng,o=sun.com 2746 objectclass: top 2747 objectclass: organizationalUnit 2749 entryLevelRights: bvt 2750 attributeLevelRights: objectclass,ou: rsc,entryACI: none 2751 --- 2752 cn=Joe Engineer,ou=Eng,o=sun.com 2753 objectclass: person 2754 cn: Joe Engineer 2755 sn: Engineer 2756 userPassword: secret 2757 salary: 10000 2759 entryLevelRights: bvt 2760 attributeLevelRights: objectclass,cn,sn: rsc 2761 userPassword,salary,entryACI: none 2762 --- 2763 ou=Sales,o=sun.com 2764 objectclass: top 2765 objectclass: organizationalUnit 2767 entryLevelRights: bvt 2768 attributeLevelRights: objectclass,ou: rsc,entryACI: none 2769 --- 2770 cn=Joe Sales,ou=Sales,o=sun.com 2771 objectclass: person 2772 cn: Joe Sales 2773 sn: Sales 2774 userPassword: secret 2775 salary: 100000000000 2777 entryLevelRights: bvtg 2778 attributeLevelRights: objectclass,cn,sn,userPassword: rscow 2779 salary,entryACI: rsc 2781 9.5 Client-Server Interaction 2783 The GetEffectiveRightsRequest control requests the rights that are in 2784 effect for requested directory entry/attribute based on the specified 2785 subject. The server that consumes the search operation looks up the 2786 rights for the returned directory information based on the subject and 2787 returns that rights information as defined above. 2789 There are six possible scenarios that may occur as a result of the 2790 GetEffectiveRights control being included on the search request: 2792 1. If the server does not support this control and the client 2793 specified TRUE for the control's criticality field, then the 2794 server MUST return unavailableCriticalExtension as a return code 2795 in the searchResponse message and not send back any other results. 2796 This behavior is specified in section 4.1.12 of [LDAPv3]. 2798 2. If the server does not support this control and the client 2799 specified FALSE for the control's criticality field, then the 2800 server MUST ignore the control and process the request as if it 2801 were not present. This behavior is specified in section 4.1.12 of 2802 [LDAPv3]. 2804 3. If the server supports this control but for some reason the server 2805 cannot process it and the client specified TRUE for the control's 2806 criticality field, then the server SHOULD do the following: return 2807 unavailableCriticalExtension as a return code in the searchResult 2808 message. 2810 4. If the server supports this control but for some reason the server 2811 cannot process it and the client specified FALSE for the control's 2812 criticality field, then the server should process as 'no rights 2813 returned' and include the result Unavailable in the 2814 GetEffectiveRightsResponse control in the searchResult message. 2816 5. If the server supports this control and can return the rights 2817 information, then it should include the GetEffectiveRightsResponse 2818 control in the searchResult message with a result of success. 2820 6. If the search request failed for any other reason, then the server 2821 SHOULD omit the GetEffectiveRightsResponse control from the 2822 searchResult message. 2824 The client application is assured that the correct rights are returned 2825 for scope of the search operation if and only if the 2826 GetEffectiveRightsResponse control returns the rights. If the server 2827 omits the GetEffectiveRightsResponse control from the searchResult 2828 message, the client SHOULD assume that the control was ignored by the 2829 server. 2831 The GetEffectiveRightsResponse control, if included by the server in the 2832 searchResponse message, should have the GetEffectiveRightsResult set to 2833 either success if the rights are returned or set to the appropriate 2834 error code as to why the rights could not be returned. 2836 The server may not be able to return a right because it may not exist in 2837 that directory object's attribute; in this case, the rights request is 2838 ignored with success. 2840 10. Security Considerations 2842 This document proposes protocol elements for transmission of security 2843 policy information. Security considerations are discussed throughout 2844 this model. Because subject security attribute information is used to 2845 evaluate decision requests, it is security-sensitive information and 2846 must be protected against unauthorized modification whenever it is 2847 stored or transmitted. 2849 Interaction of access control with other directory functions (other than 2850 the ones defined in this document) are not defined in this document, but 2851 instead in the documents where those directory functions are defined. 2852 For example, the directory replication documents should address the 2853 interaction of access control with the replication function. 2855 In general, IP addresses and DNS names should not be used as identities 2856 (subjects) since they can be easily spoofed. However, some widely- 2857 deployed implementations have long supported and continue to support IP 2858 addresses and DNS names in ACI to enforce access controls based on 2859 topology. Thus IP address and DNS name are retained in the access 2860 control model though their use should be discouraged in new deployments. 2862 It is good security practice to set defaults to the most secure 2863 settings. This is done to ensure that accidentally omitting a security 2864 field does not compromise security. Following this practice in the case 2865 of authnLevel would result in a default of "strong". This would have 2866 meant that ACI with omitted authnLevel in directories where "strong" 2867 authentication is not available (the great majority of environments at 2868 this time) would deny all access, causing confusion among users and 2869 administrators. To avoid this problem, authnLevel is required on all 2870 ACI. This has the useful side-effect of forcing administrators to think 2871 about the strength of their authentication system when setting up ACI. 2873 All of the advantages of authnLevel-based access control may be lost if 2874 system administrators do a poor job of associating actual authentication 2875 mechanisms with the authnLevels in the model. Administrators should use 2876 external guidelines (for an example, see [AUTHMAP]) if they are not 2877 completely familiar with the relative strengths of the authentication 2878 mechanisms available in their environment. In addition, administrators 2879 in replicated environments should make sure that the 2880 authnLevel/authentication mechanism mappings at all replicating sites 2881 are consistent. 2883 11. References 2885 [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: 2886 ABNF", RFC 2234, November 1997. 2888 [ATTACK] R. Shirey, "Internet Security Glossary", RFC 2828, May 2000. 2890 [ATTR] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory 2891 Access Protocol (v3)": Attribute Syntax Definitions, RFC 2252, December 2892 1997. 2894 [AUTHMAP] K. Zeilenga, "Authentication Mechanisms Levels", Internet 2895 Draft, draft-zeilenga-auth-lvl-01.txt, April 2001. 2897 [AuthMeth] M. Wahl, H. Alvestrand, J. Hodges, and R. Morgan, 2898 "Authentication Methods for LDAP", RFC 2829, May 2000. 2900 [Bradner97] S. Bradner, "Key Words for use in RFCs to Indicate 2901 Requirement Levels", RFC 2119. 2903 [DirCompMatch] S. Legg, "LDAP & X.500 Component Matching Rules", 2904 Internet Draft, draft-legg-ldapext-component-matching-02.txt, May 30, 2905 2001. 2907 [ECMA] ECMA, "Security in Open Systems: A Security Framework" ECMA 2908 TR/46, July 1988. 2910 [IPV6] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 2911 RFC 2373, July 1998. 2913 [LangCode] M. Wahl, T. Howes, "Use of Language Codes in LDAP", RFC 2596, 2914 May 1999. 2916 [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 2917 Protocol (v3)", RFC 2251, December 1997. 2919 [REQTS] E. Stokes, R. Byrne, R. Blakley, "Access Control Requirements 2920 for LDAP", RFC 2820, May 2000. 2922 [SUBENTRY] E. Reed, "LDAP Subentry Schema", Internet Draft, draft-ietf- 2923 ldup-subentry-08.txt, April 2001. 2925 [UTF] M. Wahl, S. Kille, "Lightweight Directory Access Protocol (v3)": A 2926 UTF-8 String Representation of Distinguished Names", RFC 2253, December 2927 1997. 2929 [X501] Recommendation X.501 (1993), "Information Technology--Open 2930 Systems Interconnection--The Directory: Models". 2932 [X511] ITU-T, "Information technology - Open Systems Interconnection - 2933 The Directory: Abstract service definition", ITU-T Recommendation X.511 2934 (1993) | ISO/IEC 9594-3:1994. 2936 ACKNOWLEDGEMENT 2938 This is to acknowledge the numerous companies and individuals who have 2939 contributed their valuable help and insights to the development of this 2940 specification. 2942 AUTHOR(S) ADDRESS 2944 Ellen Stokes Bob Blakley 2945 Tivoli Systems Tivoli Systems 2946 9442 Capital of Texas Hwy N 9442 Capital of Texas Hwy N 2947 Austin, TX 78759 Austin, TX 78759 2948 USA USA 2949 mail-to: estokes@tivoli.com mail-to: blakley@tivoli.com 2950 phone: +1 512 436 9098 phone: +1 512 436 1564 2951 fax: +1 512 436 1190 fax: +1 512 436 1199 2953 Debbie Rinkevich Robert Byrne 2954 Momenta Sun Microsystems 2955 --- 14 Chemin du Vieux Chene 2956 Austin, TX Meylan ZIRST 38240 2957 USA France 2958 mail-to: drinkevich@momenta.com mail-to: robert.byrne@.sun.com 2959 phone: +1 512 732 0060 ext 125 phone: +33 (0)4 76 188 205 2961 Rick Huber 2962 AT&T Laboratories 2963 200 Laurel Avenue South 2964 Middletown, NJ 07748 2965 USA 2966 mail-to: rvh@att.com 2967 phone: +1 732 420 2632 2968 fax: +1 732 368 1690 2969 CONTENTS 2971 1. Introduction................................................... 2 2973 2. The LDAPv3 Access Control Model................................ 3 2975 3. Access Control Mechanism Attributes............................ 5 2976 3.1 Root DSE Attribute for Access Control Mechanism........... 5 2977 3.2 Subentry Class Access Control Mechanism................... 5 2979 4. The Access Control Information Attributes, Syntax, and 2980 Rules.......................................................... 6 2981 4.1 The ABNF and ASN.1........................................ 7 2982 4.1.1 ACI UTF-8 String Representation 7 2983 4.1.2 ACI Binary Representation 10 2984 4.2 The Components of entryACI and subtreeACI Attributes...... 12 2985 4.2.1 Access Rights and Permissions 12 2986 4.2.2 Attributes 16 2987 4.2.3 Subjects and Associated Authentication 16 2988 4.3 Access Control Decision Making............................ 18 2989 4.3.1 The Parameters to the Access Decision 2990 Algorithm 18 2991 4.3.2 Applicability Rules 19 2992 4.3.3 Precedence Rules 22 2993 4.3.4 Access Control Decision Algorithm 24 2994 4.3.5 Precedence/Inheritance Access Decision Example 25 2996 5. Required Permissions for each LDAP Operation................... 28 2997 5.1 Bind Operation............................................ 28 2998 5.2 Search Operation.......................................... 28 2999 5.2.1 Protecting the naming attributes of DNs 31 3000 5.3 Modify Operation.......................................... 31 3001 5.4 Add Operation............................................. 32 3002 5.5 Delete Operation.......................................... 33 3003 5.6 Modify DN Operation....................................... 34 3004 5.7 Compare Operation......................................... 35 3005 5.8 Abandon Operation......................................... 35 3006 5.9 Extended Operation........................................ 35 3008 6. Required Permissions for Handling Aliases and References....... 36 3009 6.1 ACI Distribution.......................................... 36 3010 6.2 Aliases................................................... 36 3011 6.3 Referrals................................................. 37 3013 7. Controlling Access to Access Control Information............... 37 3015 8. ACI Examples................................................... 37 3016 8.1 Attribute Definition...................................... 38 3017 8.2 Modifying the entryACI and subtreeACI Values.............. 38 3018 8.3 Evaluation................................................ 40 3020 - i - 3022 8.4 ModDN..................................................... 42 3023 8.5 Interaction Among ACI..................................... 45 3024 8.6 Use of ipAddress in ACI................................... 47 3025 8.7 Use of authnLevel in ACI.................................. 49 3027 9. GetEffectiveRights Control..................................... 50 3028 9.1 Request Control........................................... 51 3029 9.2 Response Control.......................................... 52 3030 9.3 Access control for the Get Effective Rights Control....... 53 3031 9.4 Get Effective Rights example.............................. 54 3032 9.5 Client-Server Interaction................................. 57 3034 10. Security Considerations........................................ 59 3036 11. References..................................................... 59 3038 - ii - 3040 Full Copyright Statement 3042 Copyright (C) The Internet Society (2000). All Rights Reserved. 3044 This document and translations of it may be copied and furnished to 3045 others, and derivative works that comment on or otherwise explain it or 3046 assist in its implementation may be prepared, copied, published and 3047 distributed, in whole or in part, without restriction of any kind, 3048 provided that the above copyright notice and this paragraph are included 3049 on all such copies and derivative works. However, this document itself 3050 may not be modified in any way, such as by removing the copyright notice 3051 or references to the Internet Society or other Internet organizations, 3052 except as needed for the purpose of developing Internet standards in 3053 which case the procedures for copyrights defined in the Internet 3054 Standards process must be followed, or as required to translate it into 3055 languages other than English. 3057 The limited permissions granted above are perpetual and will not be 3058 revoked by the Internet Society or its successors or assigns. 3060 This document and the information contained herein is provided on an "AS 3061 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 3062 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 3063 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 3064 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 3065 FITNESS FOR A PARTICULAR PURPOSE. 3067 - iii -