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]