draft-ietf-asid-ldapv3ext-00.txt   draft-ietf-asid-ldapv3ext-01.txt 
ASID Working Group ASID Working Group Y. Yaacovi
Y. Yaacovi INTERNET-DRAFT Microsoft
INTERNET-DRAFT M. Wahl
Microsoft Critical Angle Inc.
draft-ietf-asid-ldapv3ext-00.txt
K. Settle K. Settle
Microsoft
T. Genovese
Microsoft Microsoft
Expires in six months from Expires in six months from 10 September 1996
Intended Category: Standards Track Intended Category: Standards Track
Lightweight Directory Access Protocol: Lightweight Directory Access Protocol:
Extensions for Dynamic Directory Services Extensions for Dynamic Directory Services
<draft-ietf-asid-ldapv3ext-01.txt>
1. Status of this Memo 1. Status of this Memo
This document is a proposal for extending an Internet-Draft. Internet- This document is an Internet-Draft. Internet-Drafts are working
Drafts are working documents of the Internet Engineering Task Force documents of the Internet Engineering Task Force (IETF), its areas, and
(IETF), its areas, and its working groups. Note that other groups may its working groups. Note that other groups may also distribute working
also distribute working documents as Internet-Drafts. documents as Internet-Drafts.
It is expected that the proposed extensions in this memo will eventually Internet-Drafts are draft documents valid for a maximum of six months
be folded into the LDAP V3 draft. 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 2. Abstract
This document defines the requirements for dynamic directory services
and specifies the format of request and response extended operations for
supporting client-server interoperation in a dynamic directories
environment.
The Lightweight Directory Access Protocol (LDAP) [1] supports The Lightweight Directory Access Protocol (LDAP) [1] supports
lightweight lightweight access to static directory services, allowing relatively
access to static directory services, allowing relatively fast search and 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.
update access. Static directory services store information about people
that persists in its accuracy and value over a long period of time.
Dynamic directory services are different in that they store information Dynamic directory services are different in that they store information
about people that only persists in its accuracy and value while people about people that only persists in its accuracy and value while people
are online. Though the protocol operations and attributes used by are online. Though the protocol operations and attributes used by
dynamic dynamic directory services are similar to the ones used for static
directory services are similar to the ones used for static directory directory services, clients that are bound to a dynamic directory
services, clients that are bound to a dynamic directory service need to service need to periodically refresh their presence at the server to
periodically refresh their presence at the server to keep directory keep directory entries from getting stale in the presence of client
entries from getting stale in the presence of client application application crashes.
crashes.
A flow control mechanism from the server is also described that allows a A flow control mechanism from the server is also described that allows
a server to inform clients how often they should refresh their presence.
server to inform clients how often they should refresh their presence. A 3. Requirements
precursor of this mechanism was previously described in [2]. The protocol extensions must allow accessing dynamic directories in a
standard LDAP manner, to allow clients to access static and dynamic
directories in the same way.
3. Extensions for dynamic directory services By nature of dynamic directories, entries are not persistent and clients
may go away gracefully or not. The proposed extensions must offer a
way for server to tell if entries are still valid, and to do this in a
way that will scale for a relatively large number of users. There also
must be a mechanism for clients to reestablish their entry with the
server.
The main extension we propose to add is the ability for the client to Finally, to allow clients to broadly use the dynamic extensions, they
refresh its presence with the server. This refresh is achieved by need to be registered as standard LDAP extended operations.
sending Refresh requests from the client to the server. The server
can control the rate of these requests and their frequency by sending
refresh responses.
We propose to add Refresh as an LDAP V3 protocol operation, as follows: 4. Description of Approach
LDAPMessage ::= SEQUENCE { The Lightweight Directory Access Protocol (LDAP) [1] permits additional
messageID MessageID, operation requests and responses to be added to the protocol. The
cldapUserName LDAPDN OPTIONAL, support for dynamic directories takes advantage of these to establish
protocolOp CHOICE { a mechanism to support dynamic directories which is fully integrated
<Currently defined LDAP V3 operations> with LDAP.
refreshRequest RefreshRequest,
refreshResponse RefreshResponse } }
We expect these protocol operations to be connectionless LDAP A dynamic entry is an object in the directory tree which has a time-to-live
operations. associated with it. This time-to-live is set when the entry is created.
The time-to-live is automatically decremented, and when it expires the
dynamic entry disappears. By invoking the refresh extended operation
(defined below) to re-set the time-to-live, a client can cause the entry
to remain present a while longer.
3.1. Refresh Request A dynamic entry is created by including the objectClass value given in
section 6 in the list of attributes when adding an entry. This method
is subject to standard access control restrictions.
Refresh is a protocol operation sent by a client to tell the server that The extended operation covered here, allows a client to refresh a
dynamic entry by invoking at intervals refresh operations containing
that entry's name. Dynamic entries will be treated the same as
non-dynamic entries when processing search, compare, add, delete,
modify and modifydn operations. However if clients stop sending
refresh operations for an entry, then the server will automatically
and without notification remove that entry from the directory.
This removal will be treated the same as if the client had issued a
delete operation on that entry.
There is no way to change a static entry into a dynamic one and vice-
versa. If the client is using Modify with an objectClass of dynamicObject
on a static entry, the server must return a service error either
"objectClassModsProhibited" (if the server does not allow objectClass
modifications at all) or "objectClassViolation" (if the server does allow
objectClass modifications in general).
A dynamic entry may be removed by the client using the delete operation.
This operation will be subject to access control restrictions.
A non-dynamic entry cannot be added subordinate to a dynamic entry: the
server must return an appropriate update or service error if this is
attempted.
5. Protocol Additions
5.1 Refresh Request
Refresh is a protocol operation sent by a client to tell the server that
the client is still alive and the directory entry is still accurate and the client is still alive and the directory entry is still accurate and
valuable. The client sends a Refresh request periodically based on the valuable. The client sends a Refresh request periodically based on the
value of the client refresh period (CRP). The server can request that value of the client refresh period (CRP). The server can request that
the client change this value. As long as the client sends a Refresh the client change this value. As long as the server receives a Refresh
request within the CRP,the directory entry is guaranteed to persist on request within the timeout period, the directory entry is guaranteed
the server. to persist on the server. Clients implementors should be aware that
since the intervening network between the client and server is
unreliable, a Refresh request packet may be delayed or lost while in
transit. If this occurs, the entry may disappear, and the client will
need to detect this and re-add the entry.
RefreshRequest ::= SEQUENCE { A client may request this operation by transmitting an LDAP PDU containing
version INTEGER (1 .. 127) an ExtendedRequest. An LDAP ExtendedRequest is defined as follows:
clientID INTEGER } }
Parameters of the Refresh request are: ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING }
- version: The value of this field should be the LDAP protocol version. The requestName field must be set to the string
- clientID: A client identifier. When a Refresh request arrives at the "1.3.6.1.4.1.1466.101.119.1".
server, the server will use the clientID to quickly find the appropriate
client record and update it.
The cldapUserName provided with the Refresh request could serve as the The requestValue field will contain as a value the DER-encoding of the
sending client's identifier. The DN is guaranteed to be unique, but can following ASN.1 data type:
consume substantial bandwidth for such a frequent request and it might
not be quickly accessible at the server. We propose that the server
assign client identifiers to clients. This can be done as a return value
to the Add request. The server implementation is required to ensure that SEQUENCE {
entryName [0] LDAPDN,
requestTtl [1] INTEGER
}
the client identifier is unique. The server may optionally use this The entryName field is the UTF-8 string representation of the name of the
value dynamic entry [3]. This entry must already exist.
to quickly locate the client record in Refresh requests. The client will
specify this value as the clientID in refresh calls. The requestTtl is a time in seconds (between 1 and 31557600) that the
client requests that the entry exists in the directory before it is
automatically removed. Servers are not required to accept this value
and might return a different TTL value to the client. Clients must be
The initial CRP value will be set by the server through the AddResponse. able to use this server-dictated value as their CRP.
Upon any Refresh request from a client, the server may respond with a 5.2 Refresh Response
new CRP value through a Refresh response.
Note that the server might assign a separate Time-To-Live (TTL) value If a server implements this extension, then when the request is made it
for will return an LDAP PDU containing an ExtendedResponse. An LDAP
client at the server. The TTL should always be higher than the client ExtendedResponse is defined as follows:
CRP.
3.2. Refresh Response ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
responseName [0] LDAPOID OPTIONAL,
response [1] OCTET STRING OPTIONAL,
standardResponse [2] LDAPResult }
By sending a Refresh response, the server acknowledges the receipt of a The responseName field contains the same string as that present in the
Refresh request, and can optionally dictate to the client a lower or request.
higher CRP value. This will cause the client to send more frequent or
less frequent Refresh request messages, respectively. A Refresh response
is required. The response field will contain as a value the DER-encoding of the
following ASN.1 data type:
refreshResponse ::= SEQUENCE { SEQUENCE {
LDAPResult LDAPResult, responseTtl [1] INTEGER
newCRP INTEGER (1 .. 32767) } } }
Parameters of the Refresh response are: The responseTtl field is the time in seconds which the server chooses
to have as the time-to-live field for that entry. It must not be any
smaller than that which the client requested, and it may be larger.
- newCRP: The period of time, in minutes, that the client is guaranteed If the operation was successful, the errorCode field in the
to be registered and available at the server without sending Refresh standardResponse part of an ExtendedResponse will be set to success.
requests.
If the server cannot find the client, it will respond with the In case of an error, the responseTtl field will have the value 0,
resultCode and the errorCode field will contain an appropriate value, as follows:
of compareFalse. This will be an indication to the client that it needs If the entry named by entryName could not be located, the errorCode
to re-establish its presence at the server. field will contain "noSuchObject".
If the entry is not dynamic, the errorCode field will contain
"objectClassViolation".
If the requestor does not have permission to refresh the entry,
the errorCode field will contain "insufficientAccessRights".
If the requestTtl field is too large, the errorCode field will contain
"sizeLimitExceeded".
3.3 Modification to AddResponse If a server does not implement this extension, it will return an LDAP
PDU containing an ExtendedResponse, which contains only the
standardResponse element (the responseName and response elements
will be absent). The LDAPResult element will indicate the protocolError
result code.
Refresh requests need to send the clientID as part of the request. The This request is permitted to be invoked when LDAP is carried by a
client ID is assigned by the server and will be sent to the client in connectionless transport.
the AddResponse.This requires the following change in the AddResponse.
AddResponse ::= SEQUENCE { When using a connection-oriented transport, there is no requirement that
LDAPResult LDAPResult, this operation be on the same particular connection as any other. A client
clientID INTEGER OPTIONAL,
CRP INTEGER (1 .. 32767) OPTIONAL } }
4. Implementation issues may open multiple connections, or close and then reopen a connection.
4.1 Storage of dynamic information 6. Schema Additions
All dynamic entries must have the dynamicObject value in their
objectClass attribute. This object class is defined as follows
(using the ObjectClassDescription notation of [2]):
( 1.3.6.1.4.1.1466.101.119.2 NAME 'dynamicObject'
DESC 'This class, if present in an entry, indicates that this entry has
a limited lifetime and may disappear automatically when its
time-to-live has reached 0. There are no mandatory attributes of
this class, however if the client has not supplied a value for
the entryTtl attribute, the server will provide one.'
SUP top AUXILIARY )
Furthermore, the dynamic entry must have the following operational
attribute. It is described using the AttributeTypeDescription notation
of [2]:
( 1.3.6.1.4.1.1466.101.119.3 NAME 'entryTtl'
DESC 'This operational attribute is maintained by the server and appears
to be present in every dynamic entry. The attribute is not present
when the entry does not contain the dynamicObject object class.
The value of this attribute is the time in seconds that the entry
will continue to exist before it disappears from the directory.
In the absence of intervening refresh operations, the values
returned by reading the attribute in two successive searches
are guaranteed to be nonincreasing. The smallest permissible value
is 0, indicating that the entry may disappear without warning.
The attribute is marked NO-USER-MODIFICATION since it may only be
changed using the refresh operation.'
SYNTAX 'Integer' SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
7. Client and Server Requirements
7.1 Client Requirements
Once a dynamic entry has been created, clients are responsible for
invoking the refresh extended operation, in order to keep that entry
present in the directory.
Clients must not expect that the entry will be present in the DIT after
it has timed out, however it must not either require that the server
remove the entry immediately (some servers may only process timing out
entries at intervals). If the client wishes to ensure the entry
does not exist it should issue a RemoveRequest for that entry.
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 is left unchanged and is not modified in this proposal to
return this value, a client must issue a Refresh extended operation
immediately after an Add that created a dynamic entry. The Refresh
Response will return the CRP (in responseTtl) to the client.
Clients must not refresh dynamic entries which they have not created.
Clients should always be ready to handle the case in which their entry
timed out. In such a case, the Refresh operation will fail with
an error code such as noSuchObject, and the client is expected to
re-create its entry.
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 entries when they time out.
Server are not required to do this immediately.
Servers must enforce the structural rules listed in above section 4.
Servers must ensure that the operational attribute described in section 6
is present in dynamic entries.
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 dynamic entry. Servers may
permit anonymous users to refresh entries.
Servers may require that a client which attempts to create a dynamic entry
have remove permission for that entry.
Servers which implement this extension must have the OBJECT
IDENTIFIERs, described above in section 5 for the request and response,
present as values of the supportedExtension field in the root DSE. They
must also have as values in the attributeTypes and objectClasses attributes
of their subschema subentries, the AttributeTypeDescription and
ObjectClassDescription from section 6.
8. Implementation issues
8.1 Storage of dynamic information
Dynamic information is expected to change very often. In addition, Dynamic information is expected to change very often. In addition,
Refresh requests are expected to arrive at the server very often. Refresh requests are expected to arrive at the server very often.
Disk-based databases that static directory services often use are Disk-based databases that static directory services often use are
likely inappropriate for storing dynamic information. We expect
server implementations to store the dynamic attributes in memory
sufficient to avoid paging.
If the LDAP static server and the LDAP dynamic server are separate,
we expect each of these servers to store all the attributes in the
appropriate storage mechanism (either memory-based or disk-based).
However, if the same server stores both static and dynamic attributes,
we expect that the client will tell the server that the set of
attributes it adds or modifies in a request is dynamic or static.
This can be achieved by using one attribute (objectClass) to tell
the server if the list of attributes is dynamic or static. A new
objectClass for real time object (RTObject) can be used for that.
4.2 Transport protocol
We expect refresh requests and responses to be a connectionless LDAP likely inappropriate for storing dynamic information. We recommend
protocoloperations over UDP. that server implementations store dynamic entries in memory sufficient
to avoid paging. This is not a requirement.
Using UDP can reduce the load on the server but can also introduce We expect LDAP servers to be able to store static and dynamic entries.
problems. If a Refresh request is lost, it is possible that by the If an LDAP server does not support dynamic entries, it should respond
time the client times out waiting for the response and resends the with an error code such as objectClassViolation
request, the TTL of the directory entry on the server may expire,
causing the server to remove the entry. Servers should maintain a
TTL value for directory entries that is somewhat higher than the
client's CRP. In such a case, the Refresh request that the client will 8.2 Client refresh behavior
resend because of a lost response is redundant, but harmless.
4.3 Allocation of client IDs 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.
Client IDs are allocated by the server. The typical server can allocate It is recommended that in such a case, the client will retry the
increasing numbers to clients to guarantee uniqueness. The server might Refresh operation immediately, and if this Refresh request does
also use some part of the client ID to allow it to quickly find the not get a response as well, it will resort to its original Refresh
client record at the server. For example, part of the client ID might cycle, i.e. send a Refresh request at its Client Refresh Period
be the pointer to the client record at the server, which could allow (CRP).
direct access to the record by the server.
5. Localization 9. Localization
The are no localization issues for Refresh. The are no localization issues for this extended operation.
6. Security Considerations 10. Security Considerations
There are no security issues for Refresh. Security issues are not addressed in this document. Please note, though,
that anonymous clients are able to refresh entries which they did not
create.
7. Acknowledgments 11. Acknowledgements
Robert Carney, Tony Genovese, Max Morris and William Lai had a Design ideas included in this document are based on those
significant discussed in ASID and other IETF Working Groups.
part in this proposal.
8. Authors Addresses 12. Authors Addresses
Yoram Yaacovi Yoram Yaacovi
Microsoft Microsoft
One Microsoft way One Microsoft way
Redmond, WA 98052 Redmond, WA 98052
USA USA
Phone: +1 206-936-9629 Phone: +1 206-936-9629
EMail: yoramy@microsoft.com 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
Kent Settle Kent Settle
Microsoft Microsoft
One Microsoft way One Microsoft way
Redmond, WA 98052 Redmond, WA 98052
USA USA
Phone: +1 206-936-3027 Phone: +1 206-936-3027
EMail: kentse@microsoft.com EMail: kentse@microsoft.com
9. Bibliography Tony Genovese
Microsoft
One Microsoft way
Redmond, WA 98052
USA
[1] M.Wahl, W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access Phone: +1 206-703-0852
EMail: tonyg@microsoft.com
Protocol (Version 3)". <draft-ietf-asid-ldapv3-protocol-01.txt> 13. Bibliography
[2] R. Williams, "User Location Service". <draft-williams-uls-00.txt> [1] M.Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol
(Version 3)". INTERNET DRAFT <draft-ietf-asid-ldapv3-protocol-01.txt>
[2] M.Wahl, A.Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access
Protocol Standard and Pilot Attributes". INTERNET DRAFT
<draft-ietf-asid-ldapv3-attributes-02.txt>
[3] M.Wahl, S.Kille, "Lightweight Directory Access Protocol UTF-8 String
Representation of Distinguished Names". INTERNET DRAFT
<draft-ietf-asid-ldapv3-dn-00.txt>
Expires on 10 March 1996.
 End of changes. 62 change blocks. 
144 lines changed or deleted 298 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/