Network Working Group P. Xun Internet-Draft Huawei Intended status: Standards Track S. Dawkins, Ed. Expires: April 17, 2010 Huawei (USA) October 14, 2009 Subscription/Notification for Lightweight Directory Access Protocol (LDAP) draft-dawkins-ldapext-subnot-00 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 April 17, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document extends Lightweight Directory Access Protocol (LDAP) to Xun & Dawkins Expires April 17, 2010 [Page 1] Internet-Draft LDAP Subscribe/Notify October 2009 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology in this Specification . . . . . . . . . . . . . . 3 3. Applicability of this Specification . . . . . . . . . . . . . 3 4. The Subscribe Operation . . . . . . . . . . . . . . . . . . . 3 4.1. The Subscribe Request . . . . . . . . . . . . . . . . . . 3 4.1.1. SubscribeReq.requestValue.subscribeRequestType . . . . 4 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 5. Notice of Data Changed . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Xun & Dawkins Expires April 17, 2010 [Page 2] Internet-Draft LDAP Subscribe/Notify October 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. 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. 3. Applicability of this Specification This specification describes an LDAP extension for use in a controlled network environment, which does not have firewalls or Network Address Translators (NATs). For this reason, no considerations for NAT traversal, translator binding lifetimes, etc. are included 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. 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. Xun & Dawkins Expires April 17, 2010 [Page 3] Internet-Draft LDAP Subscribe/Notify October 2009 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, notifyStart GeneralizedTime OPTIONAL } NotifyReceiver ::= SEQUENCE { entryDN LDAPDN, attributeName AttributeDescription } 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 Xun & Dawkins Expires April 17, 2010 [Page 4] Internet-Draft LDAP Subscribe/Notify October 2009 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. 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. Xun & Dawkins Expires April 17, 2010 [Page 5] Internet-Draft LDAP Subscribe/Notify October 2009 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. 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. 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 Xun & Dawkins Expires April 17, 2010 [Page 6] Internet-Draft LDAP Subscribe/Notify October 2009 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 } 5. Notice of Data Changed After a client successfully subscribes to notification of the data change in the server, if 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 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 { 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, Xun & Dawkins Expires April 17, 2010 [Page 7] Internet-Draft LDAP Subscribe/Notify October 2009 oldValue [1] SET OF value AttributeValue OPTIONAL } Fields of the Notice of Data Changed message are: 1. notificationRefData: server returns the same notificationRefData as received in the related Subscribe Request to the Notification of Data Change message. 2. notificationContent: the detailed data which has been updated. 3. state: denotes the operation that changed the attribute, i.e. the attribute has been added, deleted, or modified. 4. attributeType: denotes which attribute is changed. 5. newValue: the new value of the attribute after change. 6. oldValue: the original value of the attribute before change. The server sends the Notification of Data Change message and will not expect any response from the clients. 6. Security Considerations General security considerations in [RFC4510], especially those associated with update operations in [RFC4511], apply to this extension. 7. IANA Considerations Xun & Dawkins Expires April 17, 2010 [Page 8] Internet-Draft LDAP Subscribe/Notify October 2009 It is requested that Internet Assigned Numbers Authority (IANA) make the following assignment: 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 Legend --------------------------------------------------- E => supportedExtension N => Unsolicited Notice 8. 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, 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, Xun & Dawkins Expires April 17, 2010 [Page 9] Internet-Draft LDAP Subscribe/Notify October 2009 June 2006. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 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 April 17, 2010 [Page 10]