home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-asid-ldapv3ext-04.txt < prev    next >
Text File  |  1997-05-06  |  22KB  |  493 lines
  1. ASID Working Group                                            Y. Yaacovi     
  2. INTERNET-DRAFT                                                 Microsoft
  3.                                                                  M. Wahl
  4.                                                      Critical Angle Inc.
  5.                                                              T. Genovese
  6.                                                                Microsoft
  7.  
  8. Expires in six months from                                    1 May 1997
  9. Intended Category: Standards Track
  10.  
  11.  
  12.                    Lightweight Directory Access Protocol (v3):
  13.                     Extensions for Dynamic Directory Services
  14.                     <draft-ietf-asid-ldapv3ext-04.txt>
  15.  
  16. 1. Status of this Memo
  17.  
  18.    This document is an Internet-Draft.  Internet-Drafts are working
  19.    documents of the Internet Engineering Task Force (IETF), its areas,
  20.    and its working groups.  Note that other groups may also distribute
  21.    working documents as Internet-Drafts.
  22.  
  23.    Internet-Drafts are draft documents valid for a maximum of six months
  24.    and may be updated, replaced, or obsoleted by other documents at any
  25.    time.  It is inappropriate to use Internet-Drafts as reference
  26.    material or to cite them other than as "work in progress."
  27.  
  28.    To learn the current status of any Internet-Draft, please check the
  29.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  30.    Directories on ds.internic.net (US East Coast), nic.nordu.net
  31.    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  32.  
  33. 2.  Abstract
  34.  
  35.    This document defines the requirements for dynamic directory services
  36.    and specifies the format of request and response extended operations
  37.    for supporting client-server interoperation in a dynamic directories
  38.    environment.
  39.  
  40.    The Lightweight Directory Access Protocol (LDAP) [1] supports
  41.    lightweight access to static directory services, allowing relatively
  42.    fast search and update access.  Static directory services store
  43.    information about people that persists in its accuracy and value over
  44.    a long period of time.
  45.    
  46.    Dynamic directory services are different in that they store
  47.    information that only persists in its accuracy and value when it is
  48.    being periodically refreshed.  This information is stored as dynamic
  49.    entries in the directory.  A typical use will be a client or a person
  50.    that is either online - in which case it has an entry in the
  51.    directory, or is offline - in which case its entry disappears from the
  52.    directory.  Though the protocol operations and attributes used by
  53.    dynamic directory services are similar to the ones used for static
  54.    directory services, clients that store dynamic information in the
  55.    directory need to periodically refresh this information, in order to
  56.    prevent it from disappearing.  If dynamic entries are not refreshed
  57.    within a given timeout, they will be removed from the directory.  For
  58.    example, this will happen if the client that set them goes offline.
  59.  
  60.    A flow control mechanism from the server is also described that allows
  61.    a server to inform clients how often they should refresh their
  62.    presence.
  63.    
  64. 3. Requirements
  65.  
  66.    The protocol extensions must allow accessing dynamic information in a
  67.    directory in a standard LDAP manner, to allow clients to access static
  68.    and dynamic information in the same way.
  69.  
  70.    By definition, dynamic entries are not persistent and clients may go
  71.    away gracefully or not.  The proposed extensions must offer a way for
  72.    a server to tell if entries are still valid, and to do this in a way
  73.    that is scalable.  There also must be a mechanism for clients to
  74.    reestablish their entry with the server.
  75.  
  76.    There must be a way for clients to find out, in a standard LDAP
  77.    manner, if servers support the dynamic extensions.
  78.  
  79.    Finally, to allow clients to broadly use the dynamic extensions, the
  80.    extensions need to be registered as standard LDAP extended operations.
  81.  
  82. 4. Description of Approach
  83.  
  84.    The Lightweight Directory Access Protocol (LDAP) [1] permits
  85.    additional operation requests and responses to be added to the
  86.    protocol.  This proposal takes advantage of these to support
  87.    directories which contain dynamic information in a manner which is
  88.    fully integrated with LDAP.
  89.  
  90.    The approach described in this proposal defines dynamic entries in
  91.    order to allow implementing directories with dynamic information.  An
  92.    implementation of dynamic directories, must be able to support dynamic
  93.    directory entries.
  94.  
  95. 4.1. Dynamic Entries and the dynamicObject object class
  96.  
  97.    A dynamic entry is an object in the directory tree which has a
  98.    time-to-live associated with it.  This time-to-live is set when the
  99.    entry is created.  The time-to-live is automatically decremented, and
  100.    when it expires the dynamic entry disappears.  By invoking the refresh
  101.    extended operation (defined below) to re-set the time-to-live, a
  102.    client can cause the entry to remain present a while longer.
  103.  
  104.    A dynamic entry is created by including the objectClass value given in
  105.    section 6 in the list of attributes when adding an entry.  This method
  106.    is subject to standard access control restrictions.
  107.  
  108.    The extended operation covered here, allows a client to refresh a
  109.    dynamic entry by invoking, at intervals, refresh operations containing
  110.    that entry's name.  Dynamic entries will be treated the same as
  111.    non-dynamic entries when processing search, compare, add, delete,
  112.    modify and modifyDN operations.  However if clients stop sending
  113.    refresh operations for an entry, then the server will automatically
  114.    and without notification remove that entry from the directory.  This
  115.    removal will be treated the same as if the entry had been deleted by
  116.    an LDAP protocol operation.
  117.  
  118.    There is no way to change a static entry into a dynamic one and vice-
  119.    versa.  If the client is using Modify with an objectClass of
  120.    dynamicObject on a static entry, the server must return a service
  121.    error either "objectClassModsProhibited" (if the server does not allow
  122.    objectClass modifications at all) or "objectClassViolation" (if the
  123.    server does allow objectClass modifications in general).
  124.  
  125.    A dynamic entry may be removed by the client using the delete
  126.    operation.  This operation will be subject to access control
  127.    restrictions.
  128.  
  129.    A non-dynamic entry cannot be added subordinate to a dynamic entry:
  130.    the server must return an appropriate update or service error if this
  131.    is attempted.
  132.  
  133.    The support of dynamic attributes of an otherwise static object, are
  134.    outside the scope of this document.
  135.  
  136. 4.2 Dynamic meetings (conferences)
  137.  
  138.    The way dynamicObject is defined, it has a time-to-live associated
  139.    with it, and that's about it.  Though the most common dynamic object
  140.    is a person object, there is no specific type associated with the
  141.    dynamicObject as defined here.  By the use of the dynamic object's
  142.    attributes, one can make this object represent practically anything.
  143.  
  144.    Specifically, Meetings (conferences) can be represented by dynamic
  145.    objects.  While full-featured meeting support requires special
  146.    semantics and handling by the server (and is not in the scope of this
  147.    document), the extensions described here, provide basic meetings
  148.    support.  A meeting object can be refreshed by the meeting
  149.    participants, and when it is not, the meeting entry disappears.  The
  150.    one meeting type that is naturally supported by the dynamic extensions
  151.    is creator-owned meeting.
  152.  
  153. 4.2.1 Creator-owned meetings
  154.  
  155.    Creator-owned meetings are created by a client that sets the
  156.    time-to-live attribute for the entry, and it is this client's
  157.    responsibility to refresh the meeting entry, so that it will not
  158.    disappear.  Others might join the meeting, by modifying the
  159.    appropriate attribute, but they are not allowed to refresh the entry.
  160.    When the client that created the entry goes away, it can delete the
  161.    meeting entry, or it might disappear when its time-to-live expires.
  162.    This is consistent with the common model for dynamicObject as
  163.    described above.
  164.  
  165. 5. Protocol Additions
  166.  
  167. 5.1 Refresh Request
  168.  
  169.    Refresh is a protocol operation sent by a client to tell the server
  170.    that the client is still alive and the dynamic directory entry is
  171.    still accurate and valuable.  The client sends a Refresh request
  172.    periodically based on the value of the client refresh period (CRP).
  173.    The server can request that the client change this value.  As long as
  174.    the server receives a Refresh request within the timeout period, the
  175.    directory entry is guaranteed to persist on the server.  Client
  176.    implementers should be aware that since the intervening network
  177.    between the client and server is unreliable, a Refresh request packet
  178.    may be delayed or lost while in transit.  If this occurs, the entry
  179.    may disappear, and the client will need to detect this and re-add the
  180.    entry.
  181.  
  182.    A client may request this operation by transmitting an LDAP PDU
  183.    containing an ExtendedRequest.  An LDAP ExtendedRequest is defined as
  184.    follows:
  185.  
  186.          ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
  187.                  requestName             [0] LDAPOID,
  188.                  requestValue            [1] OCTET STRING }
  189.         
  190.    The requestName field must be set to the string
  191.    "1.3.6.1.4.1.1466.101.119.1".
  192.  
  193.    The requestValue field will contain as a value the DER-encoding of the
  194.    following ASN.1 data type:
  195.  
  196.         SEQUENCE {
  197.                 entryName  [0] LDAPDN,
  198.                 requestTtl [1] INTEGER
  199.         }
  200.  
  201.    The entryName field is the UTF-8 string representation of the name of
  202.    the dynamic entry [3].
  203.    This entry must already exist.
  204.  
  205.    The requestTtl is a time in seconds (between 1 and 31557600) that the
  206.    client requests that the entry exists in the directory before being
  207.    automatically removed.  Servers are not required to accept this value
  208.    and might return a different TTL value to the client.  Clients must be
  209.    able to use this server-dictated value as their CRP.
  210.  
  211. 5.2 Refresh Response
  212.  
  213.    If a server implements this extension, then when the request is made
  214.    it will return an LDAP PDU containing an ExtendedResponse.  An LDAP
  215.    ExtendedResponse is defined as follows:
  216.  
  217.         ExtendedResponse ::= [APPLICATION 24] SEQUENCE {      
  218.                 responseName            [0] LDAPOID OPTIONAL,
  219.                 response                [1] OCTET STRING OPTIONAL,
  220.                 standardResponse        [2] LDAPResult }
  221.  
  222.    The responseName field contains the same string as that present in the
  223.    request.
  224.  
  225.    The response field will contain as a value the DER-encoding of the
  226.    following ASN.1 data type:
  227.  
  228.         SEQUENCE {
  229.                 responseTtl [1] INTEGER
  230.         }
  231.  
  232.    The responseTtl field is the time in seconds which the server chooses
  233.    to have as the time-to-live field for that entry.  It must not be any
  234.    smaller than that which the client requested, and it may be larger.
  235.  
  236.    If the operation was successful, the errorCode field in the
  237.    standardResponse part of an ExtendedResponse will be set to success.
  238.  
  239.    In case of an error, the responseTtl field will have the value 0, and
  240.    the errorCode field will contain an appropriate value, as follows: If
  241.    the entry named by entryName could not be located, the errorCode field
  242.    will contain "noSuchObject".  If the entry is not dynamic, the
  243.    errorCode field will contain "objectClassViolation".  If the requester
  244.    does not have permission to refresh the entry, the errorCode field
  245.    will contain "insufficientAccessRights".  If the requestTtl field is
  246.    too large, the errorCode field will contain "sizeLimitExceeded".
  247.  
  248.    If a server does not implement this extension, it will return an LDAP
  249.    PDU containing an ExtendedResponse, which contains only the
  250.    standardResponse element (the responseName and response elements will
  251.    be absent).  The LDAPResult element will indicate the protocolError
  252.    result code.
  253.  
  254.    This request is permitted to be invoked when LDAP is carried by a
  255.    connectionless transport.
  256.  
  257.    When using a connection-oriented transport, there is no requirement
  258.    that this operation be on the same particular connection as any other.
  259.    A client may open multiple connections, or close and then reopen a
  260.    connection.
  261.  
  262. 6. Schema Additions
  263.  
  264.    All dynamic entries must have the dynamicObject value in their
  265.    objectClass attribute.  This object class is defined as follows (using
  266.    the ObjectClassDescription notation of [2]):
  267.  
  268.    ( 1.3.6.1.4.1.1466.101.119.2 NAME 'dynamicObject'
  269.      DESC 'This class, if present in an entry, indicates that this entry
  270.            has a limited lifetime and may disappear automatically when
  271.            its time-to-live has reached 0.  There are no mandatory
  272.            attributes of this class, however if the client has not
  273.            supplied a value for the entryTtl attribute, the server will
  274.            provide one.'
  275.      SUP top AUXILIARY )  
  276.  
  277.  
  278.    Furthermore, the dynamic entry must have the following operational
  279.    attribute.  It is described using the AttributeTypeDescription
  280.    notation of [2]:
  281.  
  282.    ( 1.3.6.1.4.1.1466.101.119.3 NAME 'entryTtl'
  283.      DESC 'This operational attribute is maintained by the server and
  284.            appears to be present in every dynamic entry.  The attribute
  285.            is not present when the entry does not contain the dynamicObject
  286.            object class. The value of this attribute is the time in seconds
  287.            that the entry will continue to exist before disappearing from
  288.            the directory.  In the absence of intervening refresh
  289.            operations, the values returned by reading the attribute in
  290.            two successive searches are guaranteed to be nonincreasing.
  291.            The smallest permissible value is 0, indicating that the entry
  292.            may disappear without warning.  The attribute is marked
  293.            NO-USER-MODIFICATION since it may only be changed using the
  294.            refresh operation.'
  295.      SYNTAX 'Integer' SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
  296.  
  297.    To allow servers to support dynamic entries in only a part of the 
  298.    DIT, the following operational attribute is defined.   It is described
  299.    using the AttributeTypeDescription notation of [2]:
  300.  
  301.    ( 1.3.6.1.4.1.1466.101.119.4 NAME 'dynamicSubtrees'
  302.      DESC 'This operational attribute is maintained by the server and
  303.            is present in the Root DSE, if the server supports the dynamic
  304.            extensions described in this draft. The attribute contains a
  305.            list of all the subtrees in this directory for which the 
  306.            server supports the dynamic extensions.'
  307.      SYNTAX 'DN' NO-USER-MODIFICATION USAGE dSAOperation )
  308.  
  309. 7. Client and Server Requirements
  310.  
  311. 7.1 Client Requirements
  312.  
  313.    Clients can find out if a server supports the dynamic extensions by
  314.    checking the supportedExtension field in the root DSE, to see if the
  315.    OBJECT IDENTIFIER described in section 5 is present. Since servers
  316.    may select to support the dynamic extensions in only some of the
  317.    subtrees of the DIT, clients must check the dynamicSubtrees
  318.    operational attribute in the root DSE to find out if the dynamic
  319.    extensions are supported on a specific subtree.
  320.  
  321.    Once a dynamic entry has been created, clients are responsible for
  322.    invoking the refresh extended operation, in order to keep that entry
  323.    present in the directory.
  324.  
  325.    Clients must not expect that a dynamic entry will be present in the
  326.    DIT after it has timed out, however it must not require that the
  327.    server remove the entry immediately (some servers may only process
  328.    timing out entries at intervals).  If the client wishes to ensure the
  329.    entry does not exist it should issue a RemoveRequest for that entry.
  330.  
  331.    Initially, a client needs to know how often it should send refresh
  332.    requests to the server.  This value is defined as the CRP (Client
  333.    Refresh Period) and is set by the server based on the entryTtl.  Since
  334.    the LDAP AddRequest operation is left unchanged and is not modified in
  335.    this proposal to return this value, a client must issue a Refresh
  336.    extended operation immediately after an Add that created a dynamic 
  337.    entry.  The Refresh Response will return the CRP (in responseTtl)
  338.    to the client.
  339.  
  340.    Clients must not issue the refresh request for dynamic entries which
  341.    they have not created.  Please note that servers which allow anonymous
  342.    clients to create and refresh dynamic entries will not be able to
  343.    enforce the above.
  344.  
  345.    Clients should always be ready to handle the case in which their entry
  346.    timed out.  In such a case, the Refresh operation will fail with an
  347.    error code such as noSuchObject, and the client is expected to
  348.    re-create its entry.
  349.  
  350.    Clients should be prepared to experience refresh operations failing
  351.    with protocolError, even though the add and any previous refresh
  352.    requests succeeded.  This might happen if a proxy between the client
  353.    and the server goes down, and another proxy is used which does not
  354.    support the Refresh extended operation.
  355.  
  356.  
  357. 7.2 Server Requirements
  358.  
  359.    Servers are responsible for removing dynamic entries when they time
  360.    out.  Servers are not required to do this immediately.
  361.   
  362.    Servers must enforce the structural rules listed in above section 4.
  363.  
  364.    Servers must ensure that the operational attribute described in
  365.    section 6 is present in dynamic entries
  366.  
  367.    Servers are permitted to check the authentication of the client
  368.    invoking a refresh extended operation, and only permit the operation
  369.    if it matches that of the client which created the dynamic entry
  370.    (please see a note about that in section 7.1).  Servers may permit
  371.    anonymous users to refresh entries.
  372.  
  373.    Servers may require that a client which attempts to create a dynamic
  374.    entry have a remove permission for that entry.
  375.  
  376.    Servers which implement the dynamic extensions must have the OBJECT
  377.    IDENTIFIER, described above in section 5 for the request and
  378.    response, present as a value of the supportedExtension field in the
  379.    root DSE.  They must also have as values in the attributeTypes and
  380.    objectClasses attributes of their subschema subentries, the
  381.    AttributeTypeDescription and ObjectClassDescription from section 6.
  382.  
  383.    Servers can limit the support of the dynamic extensions to only
  384.    some of the subtrees in the DIT. Servers indicate for which subtrees
  385.    they support the extensions, by specifying the OIDs for the
  386.    supported subtrees in the dynamicSubtrees attribute described in
  387.    section 6. If a server supports the dynamic extensions for all
  388.    naming contexts it holds, the dynamicSubtrees attribute may be
  389.    absent.
  390.  
  391. 8. Implementation issues
  392.  
  393. 8.1 Storage of dynamic information
  394.  
  395.    Dynamic information is expected to change very often.  In addition,
  396.    Refresh requests are expected to arrive at the server very often.
  397.    Disk-based databases that static directory services often use are
  398.    likely inappropriate for storing dynamic information.  We recommend
  399.    that server implementations store dynamic entries in memory sufficient
  400.    to avoid paging.  This is not a requirement.
  401.  
  402.    We expect LDAP servers to be able to store static and dynamic entries.
  403.    If an LDAP server does not support dynamic entries, it should respond
  404.    with an error code such as objectClassViolation.
  405.  
  406. 8.2 Client refresh behavior
  407.  
  408.    In some cases, the client might not get a Refresh response.  This may
  409.    happen as a result of a server crash after receiving the Refresh
  410.    request, the TCP/IP socket timing out in the connection case, or the
  411.    UDP packet getting lost in the connection-less case.
  412.  
  413.    It is recommended that in such a case, the client will retry the
  414.    Refresh operation immediately, and if this Refresh request does not
  415.    get a response as well, it will resort to its original Refresh cycle,
  416.    i.e.  send a Refresh request at its Client Refresh Period (CRP).
  417.  
  418. 9. Replication
  419.  
  420.    Replication is not addressed in this draft. There is a separate effort
  421.    in progress at the IETF on replication of static and dynamic directories.
  422.  
  423. 10. Localization
  424.    
  425.    The are no localization issues for this extended operation.
  426.  
  427. 11. Security Considerations
  428.  
  429.    Standard LDAP security rules and support apply for the extensions
  430.    described in this document, and there are no special security issues
  431.    for these extensions. Please note, though, that servers may permit
  432.    anonymous clients to refresh entries which they did not create.
  433.  
  434.    Also, Care should be taken in making use of information obtained from
  435.    directory servers that has been supplied by client, as it may now be
  436.    out of date.  In many networks, for example, IP addresses are
  437.    automatically assigned when a host connects to the network, and may be
  438.    reassigned if that host later disconnects.  An IP address obtained
  439.    from the directory may no longer be assigned to the host that placed
  440.    the address in the directory.  This issue is not specific to LDAP or
  441.    dynamic directories.
  442.  
  443. 12. Acknowledgments
  444.  
  445.    Design ideas included in this document are based on those discussed in
  446.    ASID and other IETF Working Groups.
  447.  
  448. 13. Authors Addresses
  449.  
  450.        Yoram Yaacovi
  451.        Microsoft
  452.        One Microsoft way
  453.        Redmond, WA 98052
  454.        USA
  455.  
  456.        Phone:  +1 206-936-9629
  457.        EMail:  yoramy@microsoft.com
  458.  
  459.        Mark Wahl
  460.        Critical Angle Inc.
  461.        4815 W. Braker Lane #502-385
  462.        Austin, TX 78759
  463.        USA
  464.  
  465.        EMail:  M.Wahl@critical-angle.com
  466.  
  467.        Tony Genovese
  468.        Microsoft
  469.        One Microsoft way
  470.        Redmond, WA 98052
  471.        USA
  472.  
  473.        Phone:  +1 206-703-0852
  474.        EMail:  tonyg@microsoft.com
  475.  
  476. 14. Bibliography
  477.  
  478.    [1] M.Wahl, T.  Howes, S.  Kille, "Lightweight Directory Access
  479.        Protocol (Version 3)". INTERNET DRAFT
  480.        <draft-ietf-asid-ldapv3-protocol-04.txt>
  481.  
  482.    [2] M.Wahl, A.Coulbeck, T.  Howes, S.  Kille, "Lightweight Directory
  483.        Access Protocol (v3): Attribute Syntax Definitions". INTERNET DRAFT
  484.        <draft-ietf-asid-ldapv3-attributes-04.txt>
  485.  
  486.    [3] M.Wahl, S.Kille, "Lightweight Directory Access Protocol (v3):
  487.        UTF-8 String Representation of Distinguished Names". INTERNET DRAFT
  488.        <draft-ietf-asid-ldapv3-dn-02.txt>
  489.  
  490.  
  491.    Expires on six months from the post date (see top).
  492.  
  493.