idnits 2.17.1 draft-ietf-asid-ldapv3-dynamic-08.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 525 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** There are 41 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 217: '... responseName [0] LDAPOID OPTIONAL,...' RFC 2119 keyword, line 218: '... response [1] OCTET STRING OPTIONAL,...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (3 December 1998) is 9277 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 507 looks like a reference -- Missing reference section? 'APPLICATION 23' on line 185 looks like a reference -- Missing reference section? '0' on line 217 looks like a reference -- Missing reference section? '3' on line 515 looks like a reference -- Missing reference section? 'APPLICATION 24' on line 216 looks like a reference -- Missing reference section? '2' on line 511 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ASID Working Group Y. Yaacovi 2 INTERNET-DRAFT Microsoft 3 M. Wahl 4 Critical Angle Inc. 5 T. Genovese 6 Microsoft 8 Expires in six months from 3 December 1998 9 Intended Category: Standards Track 11 Lightweight Directory Access Protocol (v3): 12 Extensions for Dynamic Directory Services 13 15 1. Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 To learn the current status of any Internet-Draft, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ds.internic.net (US East Coast), nic.nordu.net 30 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 32 2. Abstract 34 This document defines the requirements for dynamic directory services 35 and specifies the format of request and response extended operations 36 for supporting client-server interoperation in a dynamic directories 37 environment. 39 The Lightweight Directory Access Protocol (LDAP) [1] supports 40 lightweight access to static directory services, allowing relatively 41 fast search and update access. Static directory services store 42 information about people that persists in its accuracy and value over 43 a long period of time. 45 Dynamic directory services are different in that they store 46 information that only persists in its accuracy and value when it is 47 being periodically refreshed. This information is stored as dynamic 48 entries in the directory. A typical use will be a client or a person 49 that is either online - in which case it has an entry in the 50 directory, or is offline - in which case its entry disappears from the 51 directory. Though the protocol operations and attributes used by 52 dynamic directory services are similar to the ones used for static 53 directory services, clients that store dynamic information in the 54 directory need to periodically refresh this information, in order to 55 prevent it from disappearing. If dynamic entries are not refreshed 56 within a given timeout, they will be removed from the directory. For 57 example, this will happen if the client that set them goes offline. 59 A flow control mechanism from the server is also described that allows 60 a server to inform clients how often they should refresh their 61 presence. 63 3. Requirements 65 The protocol extensions must allow accessing dynamic information in a 66 directory in a standard LDAP manner, to allow clients to access static 67 and dynamic information in the same way. 69 By definition, dynamic entries are not persistent and clients may go 70 away gracefully or not. The proposed extensions must offer a way for 71 a server to tell if entries are still valid, and to do this in a way 72 that is scalable. There also must be a mechanism for clients to 73 reestablish their entry with the server. 75 There must be a way for clients to find out, in a standard LDAP 76 manner, if servers support the dynamic extensions. 78 Finally, to allow clients to broadly use the dynamic extensions, the 79 extensions need to be registered as standard LDAP extended operations. 81 4. Description of Approach 83 The Lightweight Directory Access Protocol (LDAP) [1] permits 84 additional operation requests and responses to be added to the 85 protocol. This proposal takes advantage of these to support 86 directories which contain dynamic information in a manner which is 87 fully integrated with LDAP. 89 The approach described in this proposal defines dynamic entries in 90 order to allow implementing directories with dynamic information. An 91 implementation of dynamic directories, must be able to support dynamic 92 directory entries. 94 4.1. Dynamic Entries and the dynamicObject object class 96 A dynamic entry is an object in the directory tree which has a 97 time-to-live associated with it. This time-to-live is set when the 98 entry is created. The time-to-live is automatically decremented, and 99 when it expires the dynamic entry disappears. By invoking the refresh 100 extended operation (defined below) to re-set the time-to-live, a 101 client can cause the entry to remain present a while longer. 103 A dynamic entry is created by including the objectClass value given in 104 section 6 in the list of attributes when adding an entry. This method 105 is subject to standard access control restrictions. 107 The extended operation covered here, allows a client to refresh a 108 dynamic entry by invoking, at intervals, refresh operations containing 109 that entry's name. Dynamic entries will be treated the same as 110 non-dynamic entries when processing search, compare, add, delete, 111 modify and modifyDN operations. However if clients stop sending 112 refresh operations for an entry, then the server will automatically 113 and without notification remove that entry from the directory. This 114 removal will be treated the same as if the entry had been deleted by 115 an LDAP protocol operation. 117 There is no way to change a static entry into a dynamic one and vice- 118 versa. If the client is using Modify with an objectClass of 119 dynamicObject on a static entry, the server must return a service 120 error either "objectClassModsProhibited" (if the server does not allow 121 objectClass modifications at all) or "objectClassViolation" (if the 122 server does allow objectClass modifications in general). 124 A dynamic entry may be removed by the client using the delete 125 operation. This operation will be subject to access control 126 restrictions. 128 A non-dynamic entry cannot be added subordinate to a dynamic entry: 129 the server must return an appropriate update or service error if this 130 is attempted. 132 The support of dynamic attributes of an otherwise static object, are 133 outside the scope of this document. 135 4.2 Dynamic meetings (conferences) 137 The way dynamicObject is defined, it has a time-to-live associated 138 with it, and that's about it. Though the most common dynamic object 139 is a person object, there is no specific type associated with the 140 dynamicObject as defined here. By the use of the dynamic object's 141 attributes, one can make this object represent practically anything. 143 Specifically, Meetings (conferences) can be represented by dynamic 144 objects. While full-featured meeting support requires special 145 semantics and handling by the server (and is not in the scope of this 146 document), the extensions described here, provide basic meetings 147 support. A meeting object can be refreshed by the meeting 148 participants, and when it is not, the meeting entry disappears. The 149 one meeting type that is naturally supported by the dynamic extensions 150 is creator-owned meeting. 152 4.2.1 Creator-owned meetings 154 Creator-owned meetings are created by a client that sets the 155 time-to-live attribute for the entry, and it is this client's 156 responsibility to refresh the meeting entry, so that it will not 157 disappear. Others might join the meeting, by modifying the 158 appropriate attribute, but they are not allowed to refresh the entry. 159 When the client that created the entry goes away, it can delete the 160 meeting entry, or it might disappear when its time-to-live expires. 161 This is consistent with the common model for dynamicObject as 162 described above. 164 5. Protocol Additions 166 5.1 Refresh Request 168 Refresh is a protocol operation sent by a client to tell the server 169 that the client is still alive and the dynamic directory entry is 170 still accurate and valuable. The client sends a Refresh request 171 periodically based on the value of the client refresh period (CRP). 172 The server can request that the client change this value. As long as 173 the server receives a Refresh request within the timeout period, the 174 directory entry is guaranteed to persist on the server. Client 175 implementers should be aware that since the intervening network 176 between the client and server is unreliable, a Refresh request packet 177 may be delayed or lost while in transit. If this occurs, the entry 178 may disappear, and the client will need to detect this and re-add the 179 entry. 181 A client may request this operation by transmitting an LDAP PDU 182 containing an ExtendedRequest. An LDAP ExtendedRequest is defined as 183 follows: 185 ExtendedRequest ::= [APPLICATION 23] SEQUENCE { 186 requestName [0] LDAPOID, 187 requestValue [1] OCTET STRING } 189 The requestName field must be set to the string 190 "1.3.6.1.4.1.1466.101.119.1". 192 The requestValue field will contain as a value the DER-encoding of the 193 following ASN.1 data type: 195 SEQUENCE { 196 entryName [0] LDAPDN, 197 requestTtl [1] INTEGER 198 } 200 The entryName field is the UTF-8 string representation of the name of 201 the dynamic entry [3]. 202 This entry must already exist. 204 The requestTtl is a time in seconds (between 1 and 31557600) that the 205 client requests that the entry exists in the directory before being 206 automatically removed. Servers are not required to accept this value 207 and might return a different TTL value to the client. Clients must be 208 able to use this server-dictated value as their CRP. 210 5.2 Refresh Response 212 If a server implements this extension, then when the request is made 213 it will return an LDAP PDU containing an ExtendedResponse. An LDAP 214 ExtendedResponse is defined as follows: 216 ExtendedResponse ::= [APPLICATION 24] SEQUENCE { 217 responseName [0] LDAPOID OPTIONAL, 218 response [1] OCTET STRING OPTIONAL, 219 standardResponse [2] LDAPResult } 221 The responseName field contains the same string as that present in the 222 request. 224 The response field will contain as a value the DER-encoding of the 225 following ASN.1 data type: 227 SEQUENCE { 228 responseTtl [1] INTEGER 229 } 231 The responseTtl field is the time in seconds which the server chooses 232 to have as the time-to-live field for that entry. It must not be any 233 smaller than that which the client requested, and it may be larger. 234 However, to allow servers to maintain a relatively accurate directory, 235 and to prevent clients from abusing the dynamic extensions, servers 236 are permitted to shorten a client-requested time-to-live value, down 237 to a minimum of 86400 seconds (one day). 239 If the operation was successful, the errorCode field in the 240 standardResponse part of an ExtendedResponse will be set to success. 242 In case of an error, the responseTtl field will have the value 0, and 243 the errorCode field will contain an appropriate value, as follows: If 244 the entry named by entryName could not be located, the errorCode field 245 will contain "noSuchObject". If the entry is not dynamic, the 246 errorCode field will contain "objectClassViolation". If the requester 247 does not have permission to refresh the entry, the errorCode field 248 will contain "insufficientAccessRights". If the requestTtl field is 249 too large, the errorCode field will contain "sizeLimitExceeded". 251 If a server does not implement this extension, it will return an LDAP 252 PDU containing an ExtendedResponse, which contains only the 253 standardResponse element (the responseName and response elements will 254 be absent). The LDAPResult element will indicate the protocolError 255 result code. 257 This request is permitted to be invoked when LDAP is carried by a 258 connectionless transport. 260 When using a connection-oriented transport, there is no requirement 261 that this operation be on the same particular connection as any other. 262 A client may open multiple connections, or close and then reopen a 263 connection. 265 5.3 X.500/DAP Modify(97) 267 X.500/DAP servers can map the Refresh request and response operations 268 into the X.500/DAP Modify(97) operation. 270 6. Schema Additions 272 All dynamic entries must have the dynamicObject value in their 273 objectClass attribute. This object class is defined as follows (using 274 the ObjectClassDescription notation of [2]): 276 ( 1.3.6.1.4.1.1466.101.119.2 NAME 'dynamicObject' 277 DESC 'This class, if present in an entry, indicates that this entry 278 has a limited lifetime and may disappear automatically when 279 its time-to-live has reached 0. There are no mandatory 280 attributes of this class, however if the client has not 281 supplied a value for the entryTtl attribute, the server will 282 provide one.' 283 SUP top AUXILIARY ) 285 Furthermore, the dynamic entry must have the following operational 286 attribute. It is described using the AttributeTypeDescription 287 notation of [2]: 289 ( 1.3.6.1.4.1.1466.101.119.3 NAME 'entryTtl' 290 DESC 'This operational attribute is maintained by the server and 291 appears to be present in every dynamic entry. The attribute 292 is not present when the entry does not contain the dynamicObject 293 object class. The value of this attribute is the time in seconds 294 that the entry will continue to exist before disappearing from 295 the directory. In the absence of intervening refresh 296 operations, the values returned by reading the attribute in 297 two successive searches are guaranteed to be nonincreasing. 298 The smallest permissible value is 0, indicating that the entry 299 may disappear without warning. The attribute is marked 300 NO-USER-MODIFICATION since it may only be changed using the 301 refresh operation.' 302 SYNTAX 'Integer' SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) 304 To allow servers to support dynamic entries in only a part of the 305 DIT, the following operational attribute is defined. It is described 306 using the AttributeTypeDescription notation of [2]: 308 ( 1.3.6.1.4.1.1466.101.119.4 NAME 'dynamicSubtrees' 309 DESC 'This operational attribute is maintained by the server and 310 is present in the Root DSE, if the server supports the dynamic 311 extensions described in this draft. The attribute contains a 312 list of all the subtrees in this directory for which the 313 server supports the dynamic extensions.' 314 SYNTAX 'DN' NO-USER-MODIFICATION USAGE dSAOperation ) 316 7. Client and Server Requirements 318 7.1 Client Requirements 320 Clients can find out if a server supports the dynamic extensions by 321 checking the supportedExtension field in the root DSE, to see if the 322 OBJECT IDENTIFIER described in section 5 is present. Since servers 323 may select to support the dynamic extensions in only some of the 324 subtrees of the DIT, clients must check the dynamicSubtrees 325 operational attribute in the root DSE to find out if the dynamic 326 extensions are supported on a specific subtree. 328 Once a dynamic entry has been created, clients are responsible for 329 invoking the refresh extended operation, in order to keep that entry 330 present in the directory. 332 Clients must not expect that a dynamic entry will be present in the 333 DIT after it has timed out, however it must not require that the 334 server remove the entry immediately (some servers may only process 335 timing out entries at intervals). If the client wishes to ensure the 336 entry does not exist it should issue a RemoveRequest for that entry. 338 Initially, a client needs to know how often it should send refresh 339 requests to the server. This value is defined as the CRP (Client 340 Refresh Period) and is set by the server based on the entryTtl. Since 341 the LDAP AddRequest operation is left unchanged and is not modified in 342 this proposal to return this value, a client must issue a Refresh 343 extended operation immediately after an Add that created a dynamic 344 entry. The Refresh Response will return the CRP (in responseTtl) 345 to the client. 347 Clients must not issue the refresh request for dynamic entries which 348 they have not created. If an anonymous client attempts to do so, 349 a server is permitted to return insufficientAccessRights (50) in the 350 RefreshResponse, enforcing the client to bind first. Please note 351 that servers which allow anonymous clients to create and refresh 352 dynamic entries will not be able to enforce the above. 354 Clients should always be ready to handle the case in which their entry 355 timed out. In such a case, the Refresh operation will fail with an 356 error code such as noSuchObject, and the client is expected to 357 re-create its entry. 359 Clients should be prepared to experience refresh operations failing 360 with protocolError, even though the add and any previous refresh 361 requests succeeded. This might happen if a proxy between the client 362 and the server goes down, and another proxy is used which does not 363 support the Refresh extended operation. 365 7.2 Server Requirements 367 Servers are responsible for removing dynamic entries when they time 368 out. Servers are not required to do this immediately. 370 Servers must enforce the structural rules listed in above section 4. 372 Servers must ensure that the operational attribute described in 373 section 6 is present in dynamic entries 375 Servers may permit anonymous users to refresh entries. However, to 376 eliminate the possibility of a malicious use of the Refresh 377 operation, servers may require the refreshing client to bind 378 first. A server implementation can achieve this by presenting ACLs 379 on the entryTtl attribute, and returning insufficientAccessRights 380 (50) in the RefreshResponse, if the client is not allowed to refresh 381 the entry. Doing this, though, might have performance implications 382 on the server and might impact the server's scalability. 384 Servers may require that a client which attempts to create a dynamic 385 entry have a remove permission for that entry. 387 Servers which implement the dynamic extensions must have the OBJECT 388 IDENTIFIER, described above in section 5 for the request and 389 response, present as a value of the supportedExtension field in the 390 root DSE. They must also have as values in the attributeTypes and 391 objectClasses attributes of their subschema subentries, the 392 AttributeTypeDescription and ObjectClassDescription from section 6. 394 Servers can limit the support of the dynamic extensions to only 395 some of the subtrees in the DIT. Servers indicate for which subtrees 396 they support the extensions, by specifying the OIDs for the 397 supported subtrees in the dynamicSubtrees attribute described in 398 section 6. If a server supports the dynamic extensions for all 399 naming contexts it holds, the dynamicSubtrees attribute may be 400 absent. 402 8. Implementation issues 404 8.1 Storage of dynamic information 406 Dynamic information is expected to change very often. In addition, 407 Refresh requests are expected to arrive at the server very often. 408 Disk-based databases that static directory services often use are 409 likely inappropriate for storing dynamic information. We recommend 410 that server implementations store dynamic entries in memory sufficient 411 to avoid paging. This is not a requirement. 413 We expect LDAP servers to be able to store static and dynamic entries. 414 If an LDAP server does not support dynamic entries, it should respond 415 with an error code such as objectClassViolation. 417 8.2 Client refresh behavior 419 In some cases, the client might not get a Refresh response. This may 420 happen as a result of a server crash after receiving the Refresh 421 request, the TCP/IP socket timing out in the connection case, or the 422 UDP packet getting lost in the connection-less case. 424 It is recommended that in such a case, the client will retry the 425 Refresh operation immediately, and if this Refresh request does not 426 get a response as well, it will resort to its original Refresh cycle, 427 i.e. send a Refresh request at its Client Refresh Period (CRP). 429 8.3 Configuration of refresh times 431 We recommend that servers will provide administrators with the ability 432 to configure the default client refresh period (CRP), and also a minimum 433 and maximum CRP values. This, together with allowing administrators to 434 request that the server will not change the CRP dynamically, will allow 435 administrators to set CRP values which will enforce a low refresh 436 traffic, or - on the other extreme, an highly up-to-date directory. 438 9. Replication 440 Replication is only partially addressed in this draft. There is a 441 separate effort in progress at the IETF on replication of static and 442 dynamic directories. 444 it is allowed to replicate a dynamic entry or a static entry with 445 dynamic attributes. Since the entryTtl is expressed as a relative time 446 (how many seconds till the entry will expire), replicating it means 447 that the replicated entry will be "off" by the replication time. 449 10. Localization 451 The are no localization issues for this extended operation. 453 11. Security Considerations 455 Standard LDAP security rules and support apply for the extensions 456 described in this document, and there are no special security issues 457 for these extensions. Please note, though, that servers may permit 458 anonymous clients to refresh entries which they did not create. 459 Servers are also permitted to control a refresh access to an entry 460 by requiring clients to bind before issuing a RefreshRequest. This 461 will have implications on the server performance and scalability. 463 Also, Care should be taken in making use of information obtained from 464 directory servers that has been supplied by client, as it may now be 465 out of date. In many networks, for example, IP addresses are 466 automatically assigned when a host connects to the network, and may be 467 reassigned if that host later disconnects. An IP address obtained 468 from the directory may no longer be assigned to the host that placed 469 the address in the directory. This issue is not specific to LDAP or 470 dynamic directories. 472 12. Acknowledgments 474 Design ideas included in this document are based on those discussed in 475 ASID and other IETF Working Groups. 477 13. Authors Addresses 479 Yoram Yaacovi 480 Microsoft 481 One Microsoft way 482 Redmond, WA 98052 483 USA 485 Phone: +1 206-936-9629 486 EMail: yoramy@microsoft.com 488 Mark Wahl 489 Critical Angle Inc. 490 4815 W. Braker Lane #502-385 491 Austin, TX 78759 492 USA 494 EMail: M.Wahl@critical-angle.com 496 Tony Genovese 497 Microsoft 498 One Microsoft way 499 Redmond, WA 98052 500 USA 502 Phone: +1 206-703-0852 503 EMail: tonyg@microsoft.com 505 14. Bibliography 507 [1] M.Wahl, T. Howes, S. Kille, "Lightweight Directory Access 508 Protocol (Version 3)". INTERNET DRAFT 509 511 [2] M.Wahl, A.Coulbeck, T. Howes, S. Kille, "Lightweight Directory 512 Access Protocol (v3): Attribute Syntax Definitions". INTERNET DRAFT 513 515 [3] M.Wahl, S.Kille, "Lightweight Directory Access Protocol (v3): 516 UTF-8 String Representation of Distinguished Names". INTERNET DRAFT 517 519 Expires on six months from the post date (see top).