mirror of
https://git.openldap.org/openldap/openldap.git
synced 2024-12-21 03:10:25 +08:00
340 lines
11 KiB
Plaintext
340 lines
11 KiB
Plaintext
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
INTERNET-DRAFT Kurt D. Zeilenga
|
|||
|
Intended Category: Standard Track OpenLDAP Foundation
|
|||
|
Expires in six months 11 May 2003
|
|||
|
|
|||
|
|
|||
|
The LDAP Assertion Control
|
|||
|
<draft-zeilenga-ldap-assert-00.txt>
|
|||
|
|
|||
|
|
|||
|
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 IESG for consideration as a Standard Track
|
|||
|
document. Distribution of this memo is unlimited. Technical
|
|||
|
discussion of this document will take place on the IETF LDAP
|
|||
|
Extensions Working Group 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 document defines the Lightweight Directory Access Protocol (LDAP)
|
|||
|
Assertion Control which allows a client to specify that a directory
|
|||
|
operation should only be processed if the assertion when applied to
|
|||
|
the target entry of the operation. It can be used to construct "test
|
|||
|
and set" and "test and clear" operations.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga LDAP Assertion Control [Page 1]
|
|||
|
|
|||
|
INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
|
|||
|
|
|||
|
|
|||
|
1. Overview
|
|||
|
|
|||
|
This document defines the Lightweight Directory Access Protocol (LDAP)
|
|||
|
[RFC3377] assertion control. The assertion control allows the client
|
|||
|
to specify a condition which allows the operation to be processed
|
|||
|
normally only when true. Otherwise the operation fails.
|
|||
|
|
|||
|
The control can be used with the Modify operation [RFC2251] to perform
|
|||
|
atomic "test and set" and "test and clear" operations as the the
|
|||
|
asserted condition is evaluated as an integral part the operation.
|
|||
|
The control may be attached to other update operations to support
|
|||
|
conditional add, delete, and renaming of objects.
|
|||
|
|
|||
|
The control may also be used with the search operation. Here the
|
|||
|
assertion is applied to the base object of the search before searching
|
|||
|
for objects matching the search scope and filter.
|
|||
|
|
|||
|
The control may also be used with the compare operation. Here it
|
|||
|
extends the compare operation to allow a more complex assertion.
|
|||
|
|
|||
|
|
|||
|
2. Terminology
|
|||
|
|
|||
|
Protocol elements are described using ASN.1 [X.680]. 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. The Assertion Control
|
|||
|
|
|||
|
The assertion control is an LDAP Control [RFC2251] whose controlType
|
|||
|
is IANA-ASSIGNED-OID and controlValue is a BER-encoded Filter
|
|||
|
[RFC2251, Section 4.5.1]. The criticality may be TRUE or FALSE.
|
|||
|
There is no corresponding response control.
|
|||
|
|
|||
|
Servers implementing this technical specification SHOULD publish
|
|||
|
IANA-ASSIGNED-OID as a value of the 'supportedControl' attribute
|
|||
|
[RFC2252] in their root DSE.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga LDAP Assertion Control [Page 2]
|
|||
|
|
|||
|
INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
|
|||
|
|
|||
|
|
|||
|
The control is appropriate for both LDAP interrogation and update
|
|||
|
operations [RFC2251] including Add, Compare, Delete, Modify, ModifyDN
|
|||
|
(rename), and Search. It is not appropriate for Abandon, Bind nor
|
|||
|
Unbind operations. Nor is it appropriate for the Start TLS [RFC2830]
|
|||
|
operation.
|
|||
|
|
|||
|
When the control is attached to an LDAP request, the processing of the
|
|||
|
request is conditional on the evaluation of the Filter as applied
|
|||
|
against the target of the operation. If the Filter evaluates to TRUE,
|
|||
|
then the request is processed normally. If the Filter evaluates to
|
|||
|
FALSE, then assertionFailed (IANA-ASSIGNED-CODE) resultCode is
|
|||
|
returned and no further processing is performed.
|
|||
|
|
|||
|
For Add, Compare, and ModifyDN the target is indicated by the entry
|
|||
|
field in the request. For Modify, the target is indicated by the
|
|||
|
object field. For Delete, the target is indicated by the DelRequest
|
|||
|
type. For the Compare operation and all update operations, the
|
|||
|
evaluation of the assertion MUST be performed as an integral part of
|
|||
|
the operation. That is, the evaluation of the assertion and the
|
|||
|
normal processing SHALL be done as one atomic action.
|
|||
|
|
|||
|
For search operation, the target is indicated by the baseObject field
|
|||
|
and the evaluation is done after "finding" but before "searching"
|
|||
|
[RFC2251]. Hence, if the evaluation fails, no entries or
|
|||
|
continuations references are returned.
|
|||
|
|
|||
|
Other documents may specify how this control applies to other LDAP
|
|||
|
operations. In doing so, they must how the target entry is
|
|||
|
determined.
|
|||
|
|
|||
|
|
|||
|
3. Security Considerations
|
|||
|
|
|||
|
The filter may, like other values of the request, contain sensitive
|
|||
|
information. When so, this information should be appropriately
|
|||
|
protected.
|
|||
|
|
|||
|
As with any general assertion mechanism, the mechanism can be used to
|
|||
|
determine directory content. Hence, the mechanism SHOULD be subject
|
|||
|
to appropriate access controls.
|
|||
|
|
|||
|
Some assertions may be very complex, requiring significant time and
|
|||
|
resources to evaluate. Hence, the mechanism SHOULD be subject to
|
|||
|
appropriate administrative controls.
|
|||
|
|
|||
|
All security considerations for the base operations [RFC2251] to which
|
|||
|
this control is attached to apply, as do general LDAP security
|
|||
|
considerations [RFC3377].
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga LDAP Assertion Control [Page 3]
|
|||
|
|
|||
|
INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
|
|||
|
|
|||
|
|
|||
|
4. IANA Considerations
|
|||
|
|
|||
|
4.1. Object Identifier
|
|||
|
|
|||
|
It is requested that IANA register upon Standards Action an LDAP
|
|||
|
Object Identifier [RFC3383] to identify the LDAP Assertion Control
|
|||
|
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 Assertion Control
|
|||
|
|
|||
|
4.2 LDAP Protocol Mechanism
|
|||
|
|
|||
|
Registration of this protocol mechanism [RFC3383] is requested.
|
|||
|
|
|||
|
Subject: Request for LDAP Protocol Mechanism Registration
|
|||
|
Object Identifier: IANA-ASSIGNED-OID
|
|||
|
Description: Assertion 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
|
|||
|
|
|||
|
|
|||
|
4.3 LDAP Result Code
|
|||
|
|
|||
|
Assignment of an LDAP Result Code [RFC3383] called 'assertionFailed'
|
|||
|
is requested.
|
|||
|
|
|||
|
Subject: LDAP Result Code Registration
|
|||
|
Person & email address to contact for further information:
|
|||
|
Kurt Zeilenga <kurt@OpenLDAP.org>
|
|||
|
Result Code Name: assertionFailed
|
|||
|
Specification: RFC XXXX
|
|||
|
Author/Change Controller: IESG
|
|||
|
Comments: none
|
|||
|
|
|||
|
|
|||
|
5. Acknowledgments
|
|||
|
|
|||
|
The assertion control concept is attributed to Morteza Ansari.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga LDAP Assertion Control [Page 4]
|
|||
|
|
|||
|
INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
|
|||
|
|
|||
|
|
|||
|
6. Author's Address
|
|||
|
|
|||
|
Kurt D. Zeilenga
|
|||
|
OpenLDAP Foundation
|
|||
|
<Kurt@OpenLDAP.org>
|
|||
|
|
|||
|
|
|||
|
7. 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.
|
|||
|
|
|||
|
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
|
|||
|
Protocol (v3): Technical Specification", RFC 3377,
|
|||
|
September 2002.
|
|||
|
|
|||
|
|
|||
|
8. Informative References
|
|||
|
|
|||
|
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
|
|||
|
(also RFC 3383), September 2002.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga LDAP Assertion Control [Page 5]
|
|||
|
|
|||
|
INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
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 Assertion Control [Page 6]
|
|||
|
|