mirror of
https://git.openldap.org/openldap/openldap.git
synced 2024-12-27 03:20:22 +08:00
452 lines
16 KiB
Plaintext
452 lines
16 KiB
Plaintext
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
INTERNET-DRAFT Kurt D. Zeilenga
|
|||
|
Intended Category: Standard Track OpenLDAP Foundation
|
|||
|
Expires in six months 26 October 2003
|
|||
|
|
|||
|
|
|||
|
LDAP Read Entry Controls
|
|||
|
<draft-zeilenga-ldap-readentry-01.txt>
|
|||
|
|
|||
|
|
|||
|
1. Status of this Memo
|
|||
|
|
|||
|
This document is an Internet-Draft and is in full conformance with all
|
|||
|
provisions of Section 10 of RFC2026.
|
|||
|
|
|||
|
This document is intended to be, after appropriate review and
|
|||
|
revision, submitted to the RFC Editor as a Standard Track document.
|
|||
|
Distribution of this memo is unlimited. Technical discussion of this
|
|||
|
document will take place on the IETF LDAP Extensions mailing list
|
|||
|
<ldapext@ietf.org>. Please send editorial comments directly to the
|
|||
|
author <Kurt@OpenLDAP.org>.
|
|||
|
|
|||
|
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>.
|
|||
|
|
|||
|
Copyright (C) The Internet Society (2003). All Rights Reserved.
|
|||
|
|
|||
|
Please see the Full Copyright section near the end of this document
|
|||
|
for more information.
|
|||
|
|
|||
|
|
|||
|
Abstract
|
|||
|
|
|||
|
This specification describes controls which can be attached to a
|
|||
|
Lightweight Directory Access Protocol (LDAP) update request to obtain
|
|||
|
copies of the target entry before and/or after the requested update is
|
|||
|
applied.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga LDAP Read Entry Controls [Page 1]
|
|||
|
|
|||
|
INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
|
|||
|
|
|||
|
|
|||
|
1. Background and Intent of Use
|
|||
|
|
|||
|
This specification describes controls [RFC2251] which can be attached
|
|||
|
to Lightweight Directory Access Protocol (LDAP) [RFC3377] update
|
|||
|
requests to request and return copies of the target entry. One
|
|||
|
request control, called the Pre-Read request control, indicates that a
|
|||
|
copy of the entry before application of update is to be returned.
|
|||
|
Another control, called the Post-Read request control, indicates that
|
|||
|
a copy of the entry after application of the update is to be returned.
|
|||
|
Each request control has a corresponding response control used to
|
|||
|
return the entry.
|
|||
|
|
|||
|
The functionality offered by these controls is based upon similar
|
|||
|
functionality in the X.500 Directory Access Protocol (DAP) [X.511].
|
|||
|
|
|||
|
The Pre-Read controls may be used to obtain replaced or deleted values
|
|||
|
of modified attributes or a copy of the entry being deleted.
|
|||
|
|
|||
|
The Post-Read controls may be used to obtain values of operational
|
|||
|
attributes, such as the 'entryUUID' [EntryUUID] and 'modifytimestamp'
|
|||
|
[RFC2252] attributes, updated by the server as part of the update
|
|||
|
operation.
|
|||
|
|
|||
|
|
|||
|
2. Terminology
|
|||
|
|
|||
|
Protocol elements are described using ASN.1 [X.680] with implicit
|
|||
|
tags. The term "BER-encoded" means the element is to be encoded using
|
|||
|
the Basic Encoding Rules [X.690] under the restrictions detailed in
|
|||
|
Section 5.1 of [RFC2251].
|
|||
|
|
|||
|
DN stands for Distinguished Name.
|
|||
|
DSA stands for Directory System Agent (i.e., a directory server).
|
|||
|
DSE stands for DSA-specific Entry.
|
|||
|
|
|||
|
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 BCP 14 [RFC2119].
|
|||
|
|
|||
|
|
|||
|
3. Read Entry Controls
|
|||
|
|
|||
|
3.1. The Pre-Read Controls
|
|||
|
|
|||
|
The Pre-Read request and response controls are identified by the
|
|||
|
IANA-ASSIGNED-OID.1 object identifier. Servers implementing these
|
|||
|
controls SHOULD publish IANA-ASSIGNED-OID.1 as a value of the
|
|||
|
'supportedControl' [RFC2252] in their root DSE.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga LDAP Read Entry Controls [Page 2]
|
|||
|
|
|||
|
INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
|
|||
|
|
|||
|
|
|||
|
The Pre-Read request control is an LDAP Control [RFC2251] whose
|
|||
|
controlType is IANA-ASSIGNED-OID.1 and controlValue is a BER-encoded
|
|||
|
AttributeDescriptionList [RFC2251]. The criticality may be TRUE or
|
|||
|
FALSE. This control is appropriate for the modifyRequest, delRequest,
|
|||
|
and modDNRequest LDAP messages.
|
|||
|
|
|||
|
The corresponding response control is a LDAP Control whose controlType
|
|||
|
is IANA-ASSIGNED-OID.1 and the controlValue, an OCTET STRING, contains
|
|||
|
a BER-encoded SearchResultEntry. The criticality may be TRUE or
|
|||
|
FALSE. This control is appropriate for the modifyResponse,
|
|||
|
delResponse, and modDNResponse LDAP messages with a resultCode of
|
|||
|
success (0).
|
|||
|
|
|||
|
When the request control is attached to an appropriate update LDAP
|
|||
|
request, the control requests the return of a copy of target entry
|
|||
|
prior to the application of the update. The AttributeDescriptionList
|
|||
|
indicates which attributes are requested to appear in the copy. There
|
|||
|
are two special AttributeDescriptions which may be included in the
|
|||
|
list, "*" and "+". "*" requests all user attributes. "+" requests
|
|||
|
all operational attributes. If the list is empty, all user attributes
|
|||
|
are requested. If the list contains an unrecognized attribute type,
|
|||
|
that type is simply ignored. If all attribute types are unrecognized,
|
|||
|
no attributes are to be returned. The server is to return a
|
|||
|
SearchResultEntry containing, subject to access controls and other
|
|||
|
constraints, values of the requested attributes.
|
|||
|
|
|||
|
The normal processing of the update operation and the processing of
|
|||
|
this control MUST be performed as one atomic action isolated from
|
|||
|
other update operations.
|
|||
|
|
|||
|
If the update operation fails, no response control is provided.
|
|||
|
|
|||
|
|
|||
|
3.2. The Post-Read Controls
|
|||
|
|
|||
|
The Post-Read request and response controls are identified by the
|
|||
|
IANA-ASSIGNED-OID.2 object identifier. Servers implementing these
|
|||
|
controls SHOULD publish IANA-ASSIGNED-OID.2 as a value of the
|
|||
|
'supportedControl' [RFC2252] in their root DSE.
|
|||
|
|
|||
|
The Post-Read request control is an LDAP Control [RFC2251] whose
|
|||
|
controlType is IANA-ASSIGNED-OID.2 and controlValue, an OCTET STRING,
|
|||
|
contains a BER-encoded AttributeDescriptionList [RFC2251]. The
|
|||
|
criticality may be TRUE or FALSE. This control is appropriate for the
|
|||
|
addRequest, modifyRequest, and modDNRequest LDAP messages.
|
|||
|
|
|||
|
The corresponding response control is a LDAP Control whose controlType
|
|||
|
is IANA-ASSIGNED-OID.2 and controlValue is a BER-encoded
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga LDAP Read Entry Controls [Page 3]
|
|||
|
|
|||
|
INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
|
|||
|
|
|||
|
|
|||
|
SearchResultEntry. The criticality may be TRUE or FALSE. This
|
|||
|
control is appropriate for the addResponse, modifyResponse, and
|
|||
|
modDNResponse LDAP messages with a resultCode of success (0).
|
|||
|
|
|||
|
When the request control is attached to an appropriate update LDAP
|
|||
|
request, the control requests the return of a copy of target entry
|
|||
|
after the application of the update. The AttributeDescriptionList
|
|||
|
indicates which attributes are requested to appear in the copy. There
|
|||
|
are two special AttributeDescriptions which may be included in the
|
|||
|
list, "*" and "+". "*" requests all user attributes. "+" requests
|
|||
|
all operational attributes. If the list is empty, all user attributes
|
|||
|
are requested. If the list contains an unrecognized attribute type,
|
|||
|
that type is simply ignored. If all attribute types are unrecognized,
|
|||
|
no attributes are to be returned. The server is to return a
|
|||
|
SearchResultEntry containing, subject to access controls and other
|
|||
|
constraints, values of the requested attributes.
|
|||
|
|
|||
|
The normal processing of the update operation and the processing of
|
|||
|
this control MUST be performed as one atomic action isolated from
|
|||
|
other update operations.
|
|||
|
|
|||
|
If the update operation fails, no response control is provided.
|
|||
|
|
|||
|
|
|||
|
4. Interaction with other controls
|
|||
|
|
|||
|
The Pre- and Post-Read controls may be combined with each other and/or
|
|||
|
with a variety of other controls. When combined with the assertion
|
|||
|
control [ASSERT], the manageDsaIT control [RFC3296], and/or the proxy
|
|||
|
authorization control [PROXYAUTH], the semantics of each control
|
|||
|
included in the combination apply. The Pre- and Post-Read controls
|
|||
|
may be combined with other controls as detailed in other technical
|
|||
|
specifications.
|
|||
|
|
|||
|
|
|||
|
5. Security Considerations
|
|||
|
|
|||
|
The controls defined in this document extend update operations to
|
|||
|
support read capabilities. Servers MUST ensure that the client is
|
|||
|
authorized both for reading of the information provided in this
|
|||
|
control in addition to ensuring the client is authorized to perform
|
|||
|
the requested directory update.
|
|||
|
|
|||
|
Implementors of this (or any) LDAP extension should be familiar with
|
|||
|
general LDAP security considerations [RFC3377].
|
|||
|
|
|||
|
|
|||
|
6. IANA Considerations
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga LDAP Read Entry Controls [Page 4]
|
|||
|
|
|||
|
INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
|
|||
|
|
|||
|
|
|||
|
Registration of the following protocol values [RFC3383] is requested.
|
|||
|
|
|||
|
|
|||
|
6.1. Object Identifier
|
|||
|
|
|||
|
It is requested that IANA register an LDAP Object Identifier to
|
|||
|
identify LDAP protocol elements defined in this document.
|
|||
|
|
|||
|
Subject: Request for LDAP Object Identifier Registration
|
|||
|
Person & email address to contact for further information:
|
|||
|
Kurt Zeilenga <kurt@OpenLDAP.org>
|
|||
|
Specification: RFC XXXX
|
|||
|
Author/Change Controller: IESG
|
|||
|
Comments:
|
|||
|
Identifies the LDAP Read Entry Controls
|
|||
|
|
|||
|
|
|||
|
6.2. LDAP Protocol Mechanisms
|
|||
|
|
|||
|
It is requested that IANA register the LDAP Protocol Mechanism
|
|||
|
described in this document.
|
|||
|
|
|||
|
Subject: Request for LDAP Protocol Mechanism Registration
|
|||
|
Object Identifier: IANA-ASSIGNED-OID.1
|
|||
|
Description: LDAP Pre-read Control
|
|||
|
Person & email address to contact for further information:
|
|||
|
Kurt Zeilenga <kurt@openldap.org>
|
|||
|
Usage: Control
|
|||
|
Specification: RFC XXXX
|
|||
|
Author/Change Controller: IESG
|
|||
|
Comments: none
|
|||
|
in 2
|
|||
|
|
|||
|
Subject: Request for LDAP Protocol Mechanism Registration
|
|||
|
Object Identifier: IANA-ASSIGNED-OID.2
|
|||
|
Description: LDAP Post-read Control
|
|||
|
Person & email address to contact for further information:
|
|||
|
Kurt Zeilenga <kurt@openldap.org>
|
|||
|
Usage: Control
|
|||
|
Specification: RFC XXXX
|
|||
|
Author/Change Controller: IESG
|
|||
|
Comments: none
|
|||
|
in 2
|
|||
|
|
|||
|
|
|||
|
7. Acknowledgment
|
|||
|
|
|||
|
The LDAP Pre- and Post-Read controls are modeled after similar
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga LDAP Read Entry Controls [Page 5]
|
|||
|
|
|||
|
INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
|
|||
|
|
|||
|
|
|||
|
capabilities offered in the DAP [X.511].
|
|||
|
|
|||
|
|
|||
|
8. Normative References
|
|||
|
|
|||
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
|
|||
|
|
|||
|
[RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
|
|||
|
Access Protocol (v3)", RFC 2251, December 1997.
|
|||
|
|
|||
|
[RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
|
|||
|
"Lightweight Directory Access Protocol (v3): Attribute
|
|||
|
Syntax Definitions", RFC 2252, December 1997.
|
|||
|
|
|||
|
[RFC2830] Hodges, J., R. Morgan, and M. Wahl, "Lightweight
|
|||
|
Directory Access Protocol (v3): Extension for Transport
|
|||
|
Layer Security", RFC 2830, May 2000.
|
|||
|
|
|||
|
[RFC3296] Zeilenga, K., "Named Subordinate References in
|
|||
|
Lightweight Directory Access Protocol (LDAP)
|
|||
|
Directories", RFC 3296, July 2002.
|
|||
|
|
|||
|
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
|
|||
|
Protocol (v3): Technical Specification", RFC 3377,
|
|||
|
September 2002.
|
|||
|
|
|||
|
[X.680] International Telecommunication Union -
|
|||
|
Telecommunication Standardization Sector, "Abstract
|
|||
|
Syntax Notation One (ASN.1) - Specification of Basic
|
|||
|
Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
|
|||
|
|
|||
|
[X.690] International Telecommunication Union -
|
|||
|
Telecommunication Standardization Sector, "Specification
|
|||
|
of ASN.1 encoding rules: Basic Encoding Rules (BER),
|
|||
|
Canonical Encoding Rules (CER), and Distinguished
|
|||
|
Encoding Rules (DER)", X.690(1997) (also ISO/IEC
|
|||
|
8825-1:1998).
|
|||
|
|
|||
|
[PROXYAUTH] Weltman, R., "LDAP Proxy Authentication Control", draft-
|
|||
|
weltman-ldapv3-proxy-xx.txt, a work in progress.
|
|||
|
|
|||
|
[ASSERT] Zeilenga, K., "LDAP Assertion Control",
|
|||
|
draft-zeilenga-ldap-assert-xx.txt, a work in progress.
|
|||
|
|
|||
|
|
|||
|
9. Informative References
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga LDAP Read Entry Controls [Page 6]
|
|||
|
|
|||
|
INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
|
|||
|
|
|||
|
|
|||
|
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
|
|||
|
(also RFC 3383), September 2002.
|
|||
|
|
|||
|
[X.511] International Telecommunication Union -
|
|||
|
Telecommunication Standardization Sector, "The
|
|||
|
Directory: Abstract Service Definition", X.511(1993).
|
|||
|
|
|||
|
[EntryUUID] Zeilenga, K., "The LDAP EntryUUID Operational
|
|||
|
Attribute", draft-zeilenga-ldap-uuid-xx.txt, a work in
|
|||
|
progress.
|
|||
|
|
|||
|
|
|||
|
10. Author's Address
|
|||
|
|
|||
|
Kurt D. Zeilenga
|
|||
|
OpenLDAP Foundation
|
|||
|
<Kurt@OpenLDAP.org>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Intellectual Property Rights
|
|||
|
|
|||
|
The IETF takes no position regarding the validity or scope of any
|
|||
|
intellectual property or other rights that might be claimed to pertain
|
|||
|
to the implementation or use of the technology described in this
|
|||
|
document or the extent to which any license under such rights might or
|
|||
|
might not be available; neither does it represent that it has made any
|
|||
|
effort to identify any such rights. Information on the IETF's
|
|||
|
procedures with respect to rights in standards-track and
|
|||
|
standards-related documentation can be found in BCP-11. Copies of
|
|||
|
claims of rights made available for publication and any assurances of
|
|||
|
licenses to be made available, or the result of an attempt made to
|
|||
|
obtain a general license or permission for the use of such proprietary
|
|||
|
rights by implementors or users of this specification can be obtained
|
|||
|
from the IETF Secretariat.
|
|||
|
|
|||
|
The IETF invites any interested party to bring to its attention any
|
|||
|
copyrights, patents or patent applications, or other proprietary
|
|||
|
rights which may cover technology that may be required to practice
|
|||
|
this standard. Please address the information to the IETF Executive
|
|||
|
Director.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Full Copyright
|
|||
|
|
|||
|
Copyright (C) The Internet Society (2003). All Rights Reserved.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga LDAP Read Entry Controls [Page 7]
|
|||
|
|
|||
|
INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
|
|||
|
|
|||
|
|
|||
|
This document and translations of it may be copied and furnished to
|
|||
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
or assist in its implmentation may be prepared, copied, published and
|
|||
|
distributed, in whole or in part, without restriction of any kind,
|
|||
|
provided that the above copyright notice and this paragraph are
|
|||
|
included on all such copies and derivative works. However, this
|
|||
|
document itself may not be modified in any way, such as by removing
|
|||
|
the copyright notice or references to the Internet Society or other
|
|||
|
Internet organizations, except as needed for the purpose of
|
|||
|
developing Internet standards in which case the procedures for
|
|||
|
copyrights defined in the Internet Standards process must be followed,
|
|||
|
or as required to translate it into languages other than English.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga LDAP Read Entry Controls [Page 8]
|
|||
|
|