


Network Working Group                                             P. Xun
Internet-Draft                                                    Huawei
Intended status: Standards Track                         S. Dawkins, Ed.
Expires: June 2, 2010                                       Huawei (USA)
                                                       November 29, 2009


  Subscription/Notification for Lightweight Directory Access Protocol
                                 (LDAP)
                    draft-dawkins-ldapext-subnot-02

Abstract

   This document extends Lightweight Directory Access Protocol (LDAP) to
   support subscription and notification mechanism.  An LDAP client can
   subscribe to data of interest available from an LDAP server and
   receive notifications from the LDAP server when this data is updated.
   By this means, an LDAP client can become aware of changes to data of
   interest in a timely manner.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 2, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Xun & Dawkins             Expires June 2, 2010                  [Page 1]

Internet-Draft            LDAP Subscribe/Notify            November 2009


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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 BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Background of this Specification . . . . . . . . . . . . . . .  3
   3.  Terminology in this Specification  . . . . . . . . . . . . . .  3
   4.  The Subscribe Operation  . . . . . . . . . . . . . . . . . . .  3
     4.1.  The Subscribe Request  . . . . . . . . . . . . . . . . . .  4
       4.1.1.  SubscribeReq.requestValue.subscribeRequestType . . . .  5
       4.1.2.  SubscribeReq.requestValue.notificationRefData  . . . .  5
       4.1.3.  SubscribeReq.requestValue.sendDataIndication . . . . .  5
       4.1.4.  SubscribeReq.requestValue.expiryTime . . . . . . . . .  5
       4.1.5.  SubscribeReq.subscribeContent  . . . . . . . . . . . .  5
       4.1.6.  SubscribeReq.requestValue.notifyRestriction  . . . . .  6
     4.2.  Subscribe Result . . . . . . . . . . . . . . . . . . . . .  6
     4.3.  Subscription Lifetimes . . . . . . . . . . . . . . . . . .  7
   5.  The Notification Operation . . . . . . . . . . . . . . . . . .  7
   6.  The notification Acknowledge Operation . . . . . . . . . . . .  8
   7.  Differences From Existing LDAP Synchronization Extensions  . .  9
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     11.2. Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12















Xun & Dawkins             Expires June 2, 2010                  [Page 2]

Internet-Draft            LDAP Subscribe/Notify            November 2009


1.  Introduction

   This document extends the Lightweight Directory Access Protocol
   (LDAP) ([RFC4510], [RFC4511], [RFC4512]) to allow LDAP clients to
   subscribe to data of interest available from LDAP servers and be
   notified of changes to subscribed data.

   This extension consists of one extended operation and one unsolicited
   notification message.  The Subscribe operation is used by the LDAP
   client to subscribe for interested data in LDAP server.  When the
   subscribed data are updated, the LDAP server sends the notification
   message to the related LDAP client with required data.


2.  Background of this Specification

   3GPP is developing specifications for "User Data Convergence", or
   UDC.  (The current service description for UDC is available at
   http://www.3gpp.org/ftp/Specs/archive/22_series/22.101/22101-a00.zip)

   The 3GPPP CT4 technical specification group is considering LDAP as a
   building block for this service, but LDAP lacks a way to meet one key
   requirement (from the 22.101 specification, in section 4.11.1):

      "Applications can subscribe to specific events which will likely
      occur on specific user data, and those should be notified when
      those events do appear.  The events can be changes on existing
      user data, addition of user data, and so on."

   This extension is intended to meet this specific requirement,
   allowing LDAP to be selected as the building block protocol for UDC.


3.  Terminology in this Specification

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.  [RFC2119]

   Augmented BNF ([RFC5234]) is used in this specification.


4.  The Subscribe Operation

   The Subscribe operation allows an LDAP client to create a
   subscription to specific data in an LDAP server.





Xun & Dawkins             Expires June 2, 2010                  [Page 3]

Internet-Draft            LDAP Subscribe/Notify            November 2009


4.1.  The Subscribe Request

   NOTE TO RFC EDITOR: Please replace all instances of "IANA-ASSIGNED-
   OID" with the actual value assigned by IANA, when this value is
   available.

   The Subscribe Request is an LDAPMessage of CHOICE extendedReq where
   the requestName is IANA-ASSIGNED-OID.1.  The message is defined as
   follows:


   SubscribeReq ::= [APPLICATION 23] SEQUENCE {
           requestName             LDAPOID,
           requestValue            SubscribeRequestValue }

   SubscribeRequestValue ::= SEQUENCE {
           subscribeRequestType    ENUMERATED {
                   subscribe       (0),
                   unsubscribe     (1) }
           subscribeContent        SubscribeContent,
           notifyRestriction       NotifyRestriction OPTIONAL,
           notificationRefData     LDAPString OPTIONAL,
           sendDataIndication      BOOLEAN,
           expiryTime              GeneralizedTime OPTIONAL }

   SubscribeContent ::= SEQUENCE {
           baseObject              LDAPDN,
           subscribeAttributeList  SEQUENCE OF SubscribeAttributes }

   SubscribeAttributes ::= SEQUENCE {
           attributes              AttributeSelection,
           operation               SET SIZE(1..3) OF ENUMERATED {
                           add     (0),
                           modify  (1),
                           delete  (2) } }

   NotifyRestriction ::= SEQUENCE {
           notifyTo                NotifyReceiver OPTIONAL,
           notifyStart             GeneralizedTime OPTIONAL }

   NotifyReceiver ::= SEQUENCE {
           entryDN         LDAPDN,
           attributeName   AttributeDescription }








Xun & Dawkins             Expires June 2, 2010                  [Page 4]

Internet-Draft            LDAP Subscribe/Notify            November 2009


4.1.1.  SubscribeReq.requestValue.subscribeRequestType

   This field indicates this request is a request to subscribe or
   unsubscribe.  The values of this field are:
   o  subscribe: indicates this request is to subscribe to specific data
      in LDAP server
   o  unsubscribe: indicates this request is to cancel the associated
      subscription

4.1.2.  SubscribeReq.requestValue.notificationRefData

   If present, this is an opague block of data that a client sends to
   the server in the Subscribe request and gets back unmodified in the
   Notification response when the notification is triggered.

4.1.3.  SubscribeReq.requestValue.sendDataIndication

   This indication tells the server whether to return the current values
   of the subscribed attributes listed in subscribeContent in the
   Subscribe response.

4.1.4.  SubscribeReq.requestValue.expiryTime

   If present, this is the designated time at which the subscription
   expires, specified as GeneralizedTime.  If this field is absent, the
   Subscribe request is always valid until the LDAP server receives a
   Subscribe request with the subscribeRequestType set to unsubscribe.

4.1.5.  SubscribeReq.subscribeContent

   The subscriberContent defines the content of a subscription request.

4.1.5.1.  baseObject

   This field specifies the name of object entry that LDAP clients wish
   to receive notifications for, when the object entry attributes
   change.

4.1.5.2.  SubscribeReq.subscribeContent.subscribeAttributeList

   A subscribeAttributeList lists the selected attributes that the LDAP
   client is interested in.

   o  attributes: In this field, the selected attributes in the entry
      are listed.  If the value of any attribute listed in this field is
      updated, a Notification response is sent to the client.





Xun & Dawkins             Expires June 2, 2010                  [Page 5]

Internet-Draft            LDAP Subscribe/Notify            November 2009


   o  operation: The value of this field denotes that the client is
      interested in the specific cause that results in the change of
      attribute.  In this field, one or more (of the following three)
      operations MUST be listed.
      *  add: if the attribute is added, the server sends the
         notification response.
      *  modify: if the attribute is modified, the server sends the
         notification response.
      *  delete: if the attribute is deleted, the server sends the
         notification response.

4.1.6.  SubscribeReq.requestValue.notifyRestriction

   The notifyRestriction describes how the Notice of Data Changed
   Notification is sent.

4.1.6.1.  SubscribeReq.requestValue.notifyRestriction.notifyTo

   This denotes the receiver of a Notice of Data Changed Notification of
   a related Subscribe request.  In the Subscribe request, an attribute
   name MAY be designated and the value(s) of this attribute contains
   the specific client(s) name(s) which will receive the related
   Notification.  If this field is absent, the receiver is the client
   which issues this Subscribe request.

4.1.6.1.1.  SubscribeReq.requestValue.notifyRestriction.notifyTo.entryDN

   This field describes the entry in which the designated attribute
   locates.

4.1.6.1.2.  SubscribeReq.requestValue.notifyRestriction.notifyTo.attribu
            teName

   This field denotes the attribute name which contains the specific
   client(s) name(s).

4.1.6.2.  SubscribeReq.requestValue.notifyRestriction.notifyStart

   The designated time that the Subscribe request comes into effect,
   specified as GeneralizedTime.  If this field is absent, the Subscribe
   request is valid when the server receives it.

4.2.  Subscribe Result

   The results of the Subscribe Request consist of zero or more
   SubscribeResultEntry messages followed by a single
   SubscribeResultDone message.




Xun & Dawkins             Expires June 2, 2010                  [Page 6]

Internet-Draft            LDAP Subscribe/Notify            November 2009


   The SubscribeResultEntry is present if the sendDataIndication is set
   to TRUE in the Subscribe Request.  Every SubscribeResultEntry
   represents an entry listed in subscribeContent of the Subscribe
   Request.  The SubscribeResultEntry is an IntermediateResponse message
   where the requestName is IANA-ASSIGNED-OID.2 and the requestValue is
   present and contains a SubscribeResultData type defined as follows:

   SubscribeResultData ::= SEQUENCE {
           objectName              LDAPDN,
           attributes              PartialAttributeList}

   PartialAttributeList ::= SEQUENCE OF
           partialAttribute PartialAttribute

   The SubscribeResultDone is an LDAPMessage of CHOICE extendedResp
   where the requestName is IANA-ASSIGNED-OID.3.  The message is defined
   as follows:

   SubscribeResultDone ::= [APPLICATION 24] SEQUENCE {
           COMPONENTS OF LDAPResult,
           responseName    LDAPOID }

4.3.  Subscription Lifetimes

   When a client has successfully subscribed for notifications, the
   subscription remains active until either
   o  The subscription expires, at the time specified in expiryTime, or
   o  The client explicitly "unsubscribes".


5.  The Notification Operation

   When a client successfully subscribes for notifications, when the
   subscribed data is updated (i.e. added, deleted, modified), the
   server SHALL send the Notification of Data Change message to the
   required client(s) with the data before and after the changes.

   To perform this operation, first, the server SHALL check if the
   actual notification receiver - which is designated in the value of
   parameter SubscribeReq.requestValue.notifyRestriction.notifyTo - is
   valid.

   Second, the server SHALL check if the notification receiver is
   permitted to receive the data according to the access control
   mechanism of LDAP.  Then the server SHALL send the notification
   message after all the checks are done.

   The Notice of Data Change is an Unsolicited Notification as defined



Xun & Dawkins             Expires June 2, 2010                  [Page 7]

Internet-Draft            LDAP Subscribe/Notify            November 2009


   in [RFC4511].  The responseName field of the Notice of Data Changed
   message is IANA-ASSIGNED-OID.4 and the responseValue is present and
   contains a BER-encoded NotifyResponseValue.


   NotifyResponseValue ::= SEQUENCE {
           notificationID          INTEGER (0 ..  maxInt),
           notificationRefData     LDAPString OPTIONAL,
           notifyContent           SEQUENCE OF NotifyEntry }

   NotifyEntry ::= SEQUENCE {
           baseObject              LDAPDN,
           notifyAttributeList     SEQUENCE OF NotifyAttribute }

   NotifyAttribute ::= SEQUENCE {
           state                   ENUMERATED {
                           add     (0),
                           modify  (1),
                           delete  (2) }
           attributeType           AttributeDesciption,
           newValue [0] SET OF value AttributeValue OPTIONAL,
           oldValue [1] SET OF value AttributeValue OPTIONAL
   }

   Fields of the Notice of Data Changed message are:
   1.  notificationID: notification identifier which is the unique
       identifier of the notification operation.
   2.  notificationRefData: server returns the same notificationRefData
       as received in the related Subscribe Request to the Notification
       of Data Change message.
   3.  notificationContent: the detailed data which has been updated.
   4.  state: denotes the operation that changed the attribute, i.e. the
       attribute has been added, deleted, or modified.
   5.  attributeType: denotes which attribute is changed.
   6.  newValue: the new value of the attribute after change.
   7.  oldValue: the original value of the attribute before change.

   The server sends the Notification of Data Change message and waits
   for the acknowledge from the clients.


6.  The notification Acknowledge Operation

   The Notification Acknowledge Operation is intended to response the
   notification sent by LDAP server.  The Notification Acknowledge is an
   LDAPMessage of CHOICE extendedReq where the requestName is IANA-
   ASSIGNED-OID.5 The requestValue is information in the form of
   NotificatinAckValue, encapsulated inside an OCTET STRING.



Xun & Dawkins             Expires June 2, 2010                  [Page 8]

Internet-Draft            LDAP Subscribe/Notify            November 2009


   NotificationAckValue ::= SEQUENCE {
           notificationID  INTEGER (0 ..  maxInt),
           resultCode              ENUMERATED      {
                           success (0),
                           failure (1),
   }

   Fields of the Notification Acknowledge message are:
   1.  notificationID: notification identifier which is same as the
       value of notificationID denoted in the Notification Operation.
   2.  resultCode: the result of Notification Operation.

   There is no response defined in the notification acknowledge
   operation.  Upon receipt of an notification acknowledge, if failure
   is indicated and any other client is available, the server selects
   another available client and sends the notification to the selected
   client.  Otherwise, the server terminites the process of
   notification.


7.  Differences From Existing LDAP Synchronization Extensions

   LDAP already provides extension (LDAP Content Sync [RFC4533], LCUP in
   RFC 3928 [RFC3928], and Persistent Search in the now-expired
   draft-smith-psearch-ldap-01) that might be used to to notify an LDAP
   client of changes to data of interest stored on an LDAP server.  We
   proposed a new SUBSCRIBE/NOTIFY extension to satisfiy the following
   requirements.

   1.  This mechanism does not require a persistent LDAP session in
       order to notify the LDAP client of changes to data of interest in
       a timely manner.  We believe this is a useful advantage when
       large numbers of LDAP clients wish to subscribe for
       notifications.
   2.  In current LDAP mechanisms, the server will notify the client of
       all changes but the client may require notifications only for
       changes which meet some condition, such as addition, modification
       or deletion.
   3.  Current LDAP mechanisms are used to synchronize the data copy in
       the LDAP client to the server, so in the first phase the server
       will return all of the data by default.  But in some case the
       client only needs to discover what has changed, and doesn't need
       to receive all of the data.

   The Subscribe/Notify mechanism allows the LDAP Server to notify
   Clients of changes in real-time, and LDAP Server doesn't need to
   maintain many simultaneous LDAP sessions.




Xun & Dawkins             Expires June 2, 2010                  [Page 9]

Internet-Draft            LDAP Subscribe/Notify            November 2009


8.  Security Considerations

   SUBSCRIBE/NOTIFY has enough in common with [RFC4533] and [RFC3928] to
   share many of the same security considerations - we have reused text
   from both [RFC4533] and [RFC3928] in this specification.

   General security considerations in [RFC4510], especially those
   associated with update operations in [RFC4511], apply to this
   extension.

   General security considerations in [RFC4513] also apply to this
   extension.

   In some situations, it may be important to prevent general exposure
   of information about changes that occur in an LDAP server.
   Therefore, servers that implement the mechanism described in this
   document SHOULD provide a means to enforce access control on the
   entries returned and MAY also provide specific access control
   mechanisms to control the use of the controls and extended operations
   defined in this document.

   The operation may be the target of direct denial-of-service attacks.
   Implementors should provide safeguards to ensure the operation is not
   abused.  Servers may place access control or other restrictions upon
   the use of this operation.

   Note that even small updates to the directory may cause a significant
   amount of traffic to be generated to clients using this operation.  A
   user could abuse its update privileges to mount an indirect denial of
   service to these clients, other clients, and/or portions of the
   network.  Servers should provide safeguards to ensure that update
   operations are not abused.


9.  IANA Considerations

   It is requested that Internet Assigned Numbers Authority (IANA) make
   the following assignment:













Xun & Dawkins             Expires June 2, 2010                 [Page 10]

Internet-Draft            LDAP Subscribe/Notify            November 2009


   Subject: Request for LDAP Protocol Mechanism Registration
   Object Identifier: see table
   Description: see table
   Person and email address to contact for further information:
           Peng Xun xunpeng@huawei.com

   NOTE TO RFC EDITOR: Please replace all instances of
                           XXXX with the RFC number
                           for this specification when it is
                           assigned.
   Specification: RFC XXXX

   Author/Change Controller: IESG

   Comments:

   Object Identifier   Type Description
   ------------------- ---- -------------------------
   IANA-ASSIGNED-OID.1  E  Subscribe Extended Request
   IANA-ASSIGNED-OID.2  E  SubscribeResultEntry Extended
                                    IntermediateResponse
   IANA-ASSIGNED-OID.3  E  SubscribeResultDone Extended
                                    Response
   IANA-ASSIGNED-OID.4  N  Notice of Data Changed
   IANA-ASSIGNED-OID.5  E  Notification Acknowledge Extended Request

   Legend
   ---------------------------------------------------
   E => supportedExtension
   N => Unsolicited Notice


10.  Acknowledgements

   The authors would like to thank Ludovic Poitou, Steven Legg, Alexey
   Melnikov, and Kurt Zeilenga, who provided feedback on the previous
   version of this draft.


11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4510]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): Technical Specification Road Map", RFC 4510,



Xun & Dawkins             Expires June 2, 2010                 [Page 11]

Internet-Draft            LDAP Subscribe/Notify            November 2009


              June 2006.

   [RFC4511]  Sermersheim, J., "Lightweight Directory Access Protocol
              (LDAP): The Protocol", RFC 4511, June 2006.

   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): Directory Information Models", RFC 4512,
              June 2006.

   [RFC4513]  Harrison, R., "Lightweight Directory Access Protocol
              (LDAP): Authentication Methods and Security Mechanisms",
              RFC 4513, June 2006.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

11.2.  Informative References

   [RFC3928]  Megginson, R., Smith, M., Natkovich, O., and J. Parham,
              "Lightweight Directory Access Protocol (LDAP) Client
              Update Protocol (LCUP)", RFC 3928, October 2004.

   [RFC4533]  Zeilenga, K. and J. Choi, "The Lightweight Directory
              Access Protocol (LDAP) Content Synchronization Operation",
              RFC 4533, June 2006.


Authors' Addresses

   Peng Xun
   Huawei Technologies Co., Ltd.

   Email: xunpeng@huawei.com


   Spencer Dawkins (editor)
   Huawei Technologies (USA)

   Phone: +1 214 755 3870
   Email: spencer@wonderhamster.org











Xun & Dawkins             Expires June 2, 2010                 [Page 12]


