ASID Working Group Y. Yaacovi INTERNET-DRAFT Microsoft M. Wahl Critical Angle Inc. T. Genovese Microsoft Expires in six months from 1 July 1997 Intended Category: Standards Track Lightweight Directory Access Protocol: Dynamic Attributes 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 2. Abstract This document defines dynamic attributes and the fashion in which they are being set and used on entries in the directory. This document builds heavily on the dynamic extensions to LDAP infrastructure as defined in [1]. The Lightweight Directory Access Protocol (LDAP) [2] supports lightweight access to static directory services, allowing relatively fast search and update access. Static directory services store information about people that persists in its accuracy and value over a long period of time. The dynamic extension to LDAP as defined in [1] added the concept of dynamic entries that only persist in the directory, when they are periodically refreshed. This document takes this approach one step farther and defines how dynamic attributes can be used, on either static or dynamic entries, to handle up-to-date and dynamic information about an entry in the directory. An example use will be a client or a person that has a static entry in the directory and sometimes goes online, which is reflected in the 'online' attribute for the entry. To specify whether this person is online or offline - an attribute that changes frequently, a client application will have to modify this attribute relatively frequently. The current location of a person is another attribute that may change frequently. Dynamic attributes must be periodically refreshed. Otherwise, they will disappear from the directory over time. 3. Requirements Dynamic attributes must be set and used in a standard LDAP manner, to allow clients to access static and dynamic attributes in the same way. By definition, dynamic attributes are not persistent and may go away gracefully or not. The proposed draft must offer a way for a server to tell if attributes are still valid, and to do this in a way that is scalable. There also must be a mechanism for clients to reestablish their attributes with the server. Dynamic attributes must build on the same infrastructure that was design into LDAP in the dynamic extensions draft ([1]). It should take advantage of the extensions and operational attributes defined [1]. Finally, to allow clients to broadly use dynamic attributes, they must be able to find out if a server supports such attributes. 4. Description of Approach The Lightweight Directory Access Protocol (LDAP) [2] supports the use of attributes on entries in the directory. The dynamic extensions draft ([1]) added support for dynamic entries. This proposal takes the attributes model and the dynamic model and merges the two to provide support for dynamic attributes in a manner which is fully compatible with LDAP. The approach taken here is to mark dynamic attributes as dynamic (described below), and require clients to refresh these attributes periodically in order to guarantee that they will continue to be present on the entry. Dynamic attributes can be set on either a static or dynamic entry, and the time-to-live associated with them applies to ALL the dynamic attributes on an entry, i.e. there is no time-to-live per dynamic attribute. This provides for a more scalable design, and a less complex server implementation. 4.1. Dynamic Attributes Dynamic attributes behave the same as ordinary user attributes to Search, Compare and Modify requests, except that if they time out they disappear from the entry in which they are located. Unlike the dynamicObject class - which is used to mark entries as dynamic, the entry itself does not disappear, and non-dynamic attributes are unaffected. Like dynamic entries, a static entry with dynamic attributes must have the entryTtl attribute which is described in [1]. Dynamic attributes do not necessarily introduce a new set of attributes in the schema. Any static attribute in the schema can be made dynamic by including the ;dynamic attribute modifier with the typename. It is allowed to introduce new dynamic attributes which are not useful in the static domain. Such attributes will still require including the ;dynamic attribute modifier with the typename to define them as dynamic. A dynamic attribute may be a subtype of a non-dynamic attribute, but a non-dynamic attribute must not be a subtype of a dynamic attribute. Operational attributes and collective attributes must not be dynamic. All dynamic attributes are considered to be user attributes, however they are not guaranteed to be present in shadow copies of entries. A client may introduce dynamic attributes into an entry by using a Modify request to add them, or by including them in the attribute list of an Add Request. If the attribute type is permitted in the entry then the dynamic attribute is also permitted. The client would specify that the attribute is dynamic by including the tag ";dynamic" with the typename. Dynamic values may be changed, and the attributes removed, by using the Modify request as normal. If the entry is deleted, dynamic attributes disappear immediately along with all the non-dynamic. A ;dynamic modifier on an attribute must not be used in a compare request, or in a search request (either in the filter or attributes requested for return). This is in keeping with the philosophy that dynamic attributes be indistinguishable from static attributes as much as possible. In such a case, a server is expected to reject the request, returning 'invalidAttributeSyntax'. The granularity of a dynamic attribute is the entire attribute including all values. Dynamic and static values may not be mixed within a single attribute. For example, suppose an existing static entry had an attribute called "ipAddress" with the value "1.2.3.4". A modification of the entry to add the value "5.4.3.2" to the attribute "ipAddress;dynamic" would fail with a "constraintViolation" error. The addition and modification of dynamic attributes are subject to schema and access control restrictions, as with non-dynamic attributes. Thus unless the extensibleObject object class is present, generally an object class or content rule must be defined to permit those attributes to be present in an entry. If their presence is controlled by an object class, then just as with non-dynamic attributes, the object class value must have already been added before the attributes are added. The dynamicObject object class described in [1] does not itself permit any particular dynamic attributes. Dynamic attributes in a particular entry are refreshed using the Refresh extended operation. All of the entry's dynamic attributes are refreshed by a single refresh request. The TTL given in the refresh response applies to all of the entry's dynamic attributes. There is no way to refresh particular dynamic attributes within an entry at different times, or to have different TTLs apply to different dynamic attributes or different values of the same multi-value dynamic attribute. If not refreshed, all dynamic attributes in an entry time out simultaneously. All the attributes which are dynamic with all their values disappear atomically, as if the server had done a ModifyEntry specifying that all the dynamic types were to be deleted from that entry. The client must not expect any dynamic attributes to be present in an entry after the time-to-live for that entry has reached zero. However the attributes may not disappear immediately as servers may only process timing out attributes at intervals (e.g. every few minutes). Note that if an object class definition references a dynamic attribute as a mandatory attribute, the attributes of the entry will still time out, but a schema inconsistency will be present in that entry. (The objectClass attribute and its values always remain since objectClass is not a dynamic attribute.) Thus it is strongly recommended that designers not specify dynamic attributes as anything other than optional attributes of auxiliary classes. Dynamic attributes may be used within dynamic entries (i.e., entries containing object class "dynamicObject", defined in [1]), but since all of such an entry's attributes are implicitly dynamic, such use is superfluous. 5. Protocol Additions Support of dynamic attributes in LDAP does not require any protocol additions beyond the Refresh request and response which were introduced in [1]. 6. Schema Additions An entry in the directory which has dynamic attributes must have the entryTtl operational attribute. In addition, the dynamicSubtrees attribute, if present in the root DSE, indicates which subtrees of the directory support the dynamic extensions. The entryTtl attribute and the dynamicSubtrees attribute are defined in [1]. The following attributes are introduced as a result of allowing dynamic attributes on static entries. It is described using the AttributeTypeDescription notation of [3]: ( 1.3.6.1.4.1.1466.101.119.5 NAME 'dynamicAttributesSubtrees' DESC 'This operational attribute is maintained by the server and is present in the Root DSE, if the server supports dynamic attributes as described in this draft. The attribute contains a list of all the subtrees in this directory for which the server supports dynamic attributes.' SYNTAX 'DN' NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.2.840.113556.1.4.612 NAME 'online' DESC 'This attribute is used to indicate whether a entry is the directory is currently online or offline. This attribute should only be used with objects in the directory for which being online or offline makes sense. For example, a person object or a meeting object. Dynamic entries are always expected to be online. This attribute is optional. SYNTAX 'BOOLEAN' SINGLE-VALUE ) ( 1.2.840.113556.1.4.613 NAME 'onlineServer' DESC 'This attribute is used to indicate the DNS names of server where this entry is online. This attribute should only be used with objects in the directory for which being online or offline makes sense. If an entry is not online, the server names in this attribute are meaningless. This attribute is maintained by the client and is optional. SYNTAX 'LDAPString' ) Note that the 'online' and 'onlineServer' attributes are only examples for one particular application of dynamic attributes, and that not all entries with dynamic attributes are required to have these attributes. 7. Client and Server Requirements 7.1 Client Requirements Clients can find out if a server supports the dynamic extensions by checking the supportedExtension field in the root DSE, to see if the OBJECT IDENTIFIER described in [1] for Refresh request and response, is present. Farther, and as described in [1], clients are expected to check the dynamicSubtrees operational attribute in the root DSE to find out in which subtrees of the directory, the server selected to support the dynamic extensions. To find out if a server specifically supports dynamic attributes, and in which subtrees in the directory, clients must check the dynamicAttributesSubtrees operational attribute in the root DSE. Once an entry has been created in the directory, that has dynamic attributes, clients are responsible for invoking the refresh extended operation, in order to keep these attributes present in the entry. The same holds true for dynamic attributes that were added to an entry after its creation. Clients must not expect that a dynamic attributes will be present in an entry after they have timed out. However it must not either require that the server remove these attributes immediately (some servers may only process timing out attributes at intervals). If the client wishes to ensure an attribute does not exist it should issue a ModifyRequest to remove this attribute explicitly. Initially, a client needs to know how often it should send refresh requests to the server. This value is defined as the CRP (Client Refresh Period) and is set by the server based on the entryTtl. Since the AddRequest and ModifyRequest are left unchanged and are not modified in this proposal to return this value, a client must issue a Refresh extended operation immediately after an Add or Modify that introduced a dynamic attribute to an entry. The Refresh Response will return the CRP (in responseTtl) to the client as described in [1]. Clients must not issue the refresh request for entries to which they did not add dynamic attributes. Please note that when a client refreshes a static entry to which it added dynamic attribute(s), it refreshes ALL the dynamic attributes in this entry, including ones added by other clients. Also note that servers which allow anonymous clients to create and refresh dynamic entries and attributes will not be able to enforce the above. Clients should always be ready to handle the case in which their dynamic attributes timed out. In such a case, the Refresh operation will fail with an error code such as noSuchAttribute, and the client is expected to re-add their dynamic attributes. Clients should be prepared to experience refresh operations failing with protocolError, even though the add and any previous refresh requests succeeded. This might happen if a proxy between the client and the server goes down, and another proxy is used which does not support the Refresh extended operation. 7.2 Server Requirements Servers are responsible for removing dynamic attributes when they time out. Servers are not required to do this immediately. Servers must enforce the schema rules listed in above section 4. Servers must ensure that the entryTtl operational attribute described in [1] is present in entries that contain dynamic attributes. Servers are permitted to check the authentication of the client invoking a refresh extended operation, and only permit the operation if it matches that of the client which created the entry or added dynamic attributes to this entry (please see a note about that in section 7.1). Servers may permit anonymous users to refresh entries. Servers which implement support for dynamic attributes must have the OBJECT IDENTIFIER, described in [1] for the request and response, present as a value of the supportedExtension field in the root DSE. They must also have as values in the attributeTypes attribute of their subschema subentries, the AttributeTypeDescription for entryTtl and dynamicSubtrees, as described in [1]. 8. Implementation issues 8.1 Storage of dynamic information Dynamic information is expected to change very often. In addition, Refresh requests are expected to arrive at the server very often. Disk-based databases that static directory services often use are likely inappropriate for storing dynamic information. We recommend that server implementations store dynamic attributes in memory sufficient to avoid paging. This is not a requirement. We expect LDAP servers to be able to store static and dynamic entries. If an LDAP server does not support dynamic entries, it should respond with an error code such as objectClassViolation. Such a server might still support setting dynamic attributes on a static entry. 8.2 Client refresh behavior In some cases, the client might not get a Refresh response. This may happen as a result of a server crash after receiving the Refresh request, the TCP/IP socket timing out in the connection case, or the UDP packet getting lost in the connection-less case. It is recommended that in such a case, the client will retry the Refresh operation immediately, and if this Refresh request does not get a response as well, it will resort to its original Refresh cycle, i.e. send a Refresh request at its Client Refresh Period (CRP). 9. Localization The are no localization issues for this extended operation. 10. Security Considerations Security issues are not addressed in this document. Please note, though, that anonymous clients are able to refresh attributes which they did not add to an entry. Also, Care should be taken in making use of information obtained from directory servers that has been supplied by client, as it may now be out of date. In many networks, for example, IP addresses are automatically assigned when a host connects to the network, and may be reassigned if that host later disconnects. An IP address obtained from the directory may no longer be assigned to the host that placed the address in the directory. This issue is not specific to LDAP or dynamic directories. 11. Acknowledgments Design ideas included in this document are based on those discussed in ASID and other IETF Working Groups. 12. Authors Addresses Yoram Yaacovi Microsoft One Microsoft way Redmond, WA 98052 USA Phone: +1 206-936-9629 EMail: yoramy@microsoft.com Mark Wahl Critical Angle Inc. 4815 W. Braker Lane #502-385 Austin, TX 78759 USA EMail: M.Wahl@critical-angle.com Tony Genovese Microsoft One Microsoft way Redmond, WA 98052 USA Phone: +1 206-703-0852 EMail: tonyg@microsoft.com 13. Bibliography [1] Y.Yaacovi, M.Wahl, T.Genovese, "Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services". INTERNET DRAFT. [2] M.Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (Version 3)". INTERNET DRAFT [3] M.Wahl, A.Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions". INTERNET DRAFT Expires on six months from the post date (see top).