mirror of
https://github.com/samba-team/samba.git
synced 2024-12-22 13:34:15 +03:00
r17189: Add the new LDAP rfc series
This commit is contained in:
Simo Sorce
Gerald (Jerry) Carter
parent
0236f3b41a
commit
d3f8b813b3
395
source/ldap_server/devdocs/rfc4510.txt
Normal file
395
source/ldap_server/devdocs/rfc4510.txt
Normal file
@ -0,0 +1,395 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group K. Zeilenga, Ed.
|
||||
Request for Comments: 4510 OpenLDAP Foundation
|
||||
Obsoletes: 2251, 2252, 2253, 2254, 2255, June 2006
|
||||
2256, 2829, 2830, 3377, 3771
|
||||
Category: Standards Track
|
||||
|
||||
|
||||
Lightweight Directory Access Protocol (LDAP):
|
||||
Technical Specification Road Map
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
The Lightweight Directory Access Protocol (LDAP) is an Internet
|
||||
protocol for accessing distributed directory services that act in
|
||||
accordance with X.500 data and service models. This document
|
||||
provides a road map of the LDAP Technical Specification.
|
||||
|
||||
1. The LDAP Technical Specification
|
||||
|
||||
The technical specification detailing version 3 of the Lightweight
|
||||
Directory Access Protocol (LDAP), an Internet Protocol, consists of
|
||||
this document and the following documents:
|
||||
|
||||
LDAP: The Protocol [RFC4511]
|
||||
LDAP: Directory Information Models [RFC4512]
|
||||
LDAP: Authentication Methods and Security Mechanisms [RFC4513]
|
||||
LDAP: String Representation of Distinguished Names [RFC4514]
|
||||
LDAP: String Representation of Search Filters [RFC4515]
|
||||
LDAP: Uniform Resource Locator [RFC4516]
|
||||
LDAP: Syntaxes and Matching Rules [RFC4517]
|
||||
LDAP: Internationalized String Preparation [RFC4518]
|
||||
LDAP: Schema for User Applications [RFC4519]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 1]
|
||||
|
||||
RFC 4510 LDAP: TS Road Map June 2006
|
||||
|
||||
|
||||
The terms "LDAP" and "LDAPv3" are commonly used to refer informally
|
||||
to the protocol specified by this technical specification. The LDAP
|
||||
suite, as defined here, should be formally identified in other
|
||||
documents by a normative reference to this document.
|
||||
|
||||
LDAP is an extensible protocol. Extensions to LDAP may be specified
|
||||
in other documents. Nomenclature denoting such combinations of
|
||||
LDAP-plus-extensions is not defined by this document but may be
|
||||
defined in some future document(s). Extensions are expected to be
|
||||
truly optional. Considerations for the LDAP extensions described in
|
||||
BCP 118, RFC 4521 [RFC4521] fully apply to this revision of the LDAP
|
||||
Technical Specification.
|
||||
|
||||
IANA (Internet Assigned Numbers Authority) considerations for LDAP
|
||||
described in BCP 64, RFC 4520 [RFC4520] apply fully to this revision
|
||||
of the LDAP technical specification.
|
||||
|
||||
1.1. Conventions
|
||||
|
||||
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].
|
||||
|
||||
2. Relationship to X.500
|
||||
|
||||
This technical specification defines LDAP in terms of [X.500] as an
|
||||
X.500 access mechanism. An LDAP server MUST act in accordance with
|
||||
the X.500 (1993) series of International Telecommunication Union -
|
||||
Telecommunication Standardization (ITU-T) Recommendations when
|
||||
providing the service. However, it is not required that an LDAP
|
||||
server make use of any X.500 protocols in providing this service.
|
||||
For example, LDAP can be mapped onto any other directory system so
|
||||
long as the X.500 data and service models [X.501][X.511], as used in
|
||||
LDAP, are not violated in the LDAP interface.
|
||||
|
||||
This technical specification explicitly incorporates portions of
|
||||
X.500(93). Later revisions of X.500 do not automatically apply to
|
||||
this technical specification.
|
||||
|
||||
3. Relationship to Obsolete Specifications
|
||||
|
||||
This technical specification, as defined in Section 1, obsoletes
|
||||
entirely the previously defined LDAP technical specification defined
|
||||
in RFC 3377 (and consisting of RFCs 2251-2256, 2829, 2830, 3771, and
|
||||
3377 itself). The technical specification was significantly
|
||||
reorganized.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 2]
|
||||
|
||||
RFC 4510 LDAP: TS Road Map June 2006
|
||||
|
||||
|
||||
This document replaces RFC 3377 as well as Section 3.3 of RFC 2251.
|
||||
[RFC4512] replaces portions of RFC 2251, RFC 2252, and RFC 2256.
|
||||
[RFC4511] replaces the majority RFC 2251, portions of RFC 2252, and
|
||||
all of RFC 3771. [RFC4513] replaces RFC 2829, RFC 2830, and portions
|
||||
of RFC 2251. [RFC4517] replaces the majority of RFC 2252 and
|
||||
portions of RFC 2256. [RFC4519] replaces the majority of RFC 2256.
|
||||
[RFC4514] replaces RFC 2253. [RFC4515] replaces RFC 2254. [RFC4516]
|
||||
replaces RFC 2255.
|
||||
|
||||
[RFC4518] is new to this revision of the LDAP technical
|
||||
specification.
|
||||
|
||||
Each document of this specification contains appendices summarizing
|
||||
changes to all sections of the specifications they replace. Appendix
|
||||
A.1 of this document details changes made to RFC 3377. Appendix A.2
|
||||
of this document details changes made to Section 3.3 of RFC 2251.
|
||||
|
||||
Additionally, portions of this technical specification update and/or
|
||||
replace a number of other documents not listed above. These
|
||||
relationships are discussed in the documents detailing these portions
|
||||
of this technical specification.
|
||||
|
||||
4. Security Considerations
|
||||
|
||||
LDAP security considerations are discussed in each document
|
||||
comprising the technical specification.
|
||||
|
||||
5. Acknowledgements
|
||||
|
||||
This document is based largely on RFC 3377 by J. Hodges and R.
|
||||
Morgan, a product of the LDAPBIS and LDAPEXT Working Groups. The
|
||||
document also borrows from RFC 2251 by M. Wahl, T. Howes, and S.
|
||||
Kille, a product of the ASID Working Group.
|
||||
|
||||
This document is a product of the IETF LDAPBIS Working Group.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 3]
|
||||
|
||||
RFC 4510 LDAP: TS Road Map June 2006
|
||||
|
||||
|
||||
6. Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC4511] Sermersheim, J., Ed., "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., Ed., "Lightweight Directory Access
|
||||
Protocol (LDAP): Authentication Methods and Security
|
||||
Mechanisms", RFC 4513, June 2006.
|
||||
|
||||
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access
|
||||
Protocol (LDAP): String Representation of Distinguished
|
||||
Names", RFC 4514, June 2006.
|
||||
|
||||
[RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory
|
||||
Access Protocol (LDAP): String Representation of Search
|
||||
Filters", RFC 4515, June 2006.
|
||||
|
||||
[RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory
|
||||
Access Protocol (LDAP): Uniform Resource Locator", RFC
|
||||
4516, June 2006.
|
||||
|
||||
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
|
||||
(LDAP): Syntaxes and Matching Rules", RFC 4517, June
|
||||
2006.
|
||||
|
||||
[RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol
|
||||
(LDAP): Internationalized String Preparation", RFC
|
||||
4518, June 2006.
|
||||
|
||||
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
|
||||
Protocol (LDAP): Schema for User Applications", RFC
|
||||
4519, June 2006.
|
||||
|
||||
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
|
||||
(IANA) Considerations for the Lightweight Directory
|
||||
Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
|
||||
|
||||
[RFC4521] Zeilenga, K., "Considerations for LDAP Extensions", BCP
|
||||
118, RFC 4521, June 2006.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 4]
|
||||
|
||||
RFC 4510 LDAP: TS Road Map June 2006
|
||||
|
||||
|
||||
[X.500] International Telecommunication Union -
|
||||
Telecommunication Standardization Sector, "The
|
||||
Directory -- Overview of concepts, models and
|
||||
services", X.500(1993) (also ISO/IEC 9594-1:1994).
|
||||
|
||||
[X.501] International Telecommunication Union -
|
||||
Telecommunication Standardization Sector, "The
|
||||
Directory -- Models", X.501(1993) (also ISO/IEC 9594-
|
||||
2:1994).
|
||||
|
||||
[X.511] International Telecommunication Union -
|
||||
Telecommunication Standardization Sector, "The
|
||||
Directory: Abstract Service Definition", X.511(1993)
|
||||
(also ISO/IEC 9594-3:1993).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 5]
|
||||
|
||||
RFC 4510 LDAP: TS Road Map June 2006
|
||||
|
||||
|
||||
Appendix A. Changes to Previous Documents
|
||||
|
||||
This appendix outlines changes this document makes relative to the
|
||||
documents it replaces (in whole or in part).
|
||||
|
||||
A.1. Changes to RFC 3377
|
||||
|
||||
This document is nearly a complete rewrite of RFC 3377 as much of the
|
||||
material of RFC 3377 is no longer applicable. The changes include
|
||||
redefining the terms "LDAP" and "LDAPv3" to refer to this revision of
|
||||
the technical specification.
|
||||
|
||||
A.2. Changes to Section 3.3 of RFC 2251
|
||||
|
||||
The section was modified slightly (the word "document" was replaced
|
||||
with "technical specification") to clarify that it applies to the
|
||||
entire LDAP technical specification.
|
||||
|
||||
Author's Address
|
||||
|
||||
Kurt D. Zeilenga
|
||||
OpenLDAP Foundation
|
||||
|
||||
EMail: Kurt@OpenLDAP.org
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 6]
|
||||
|
||||
RFC 4510 LDAP: TS Road Map June 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights 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; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 7]
|
||||
|
||||
3811
source/ldap_server/devdocs/rfc4511.txt
Normal file
3811
source/ldap_server/devdocs/rfc4511.txt
Normal file
File diff suppressed because it is too large
Load Diff
2915
source/ldap_server/devdocs/rfc4512.txt
Normal file
2915
source/ldap_server/devdocs/rfc4512.txt
Normal file
File diff suppressed because it is too large
Load Diff
1907
source/ldap_server/devdocs/rfc4513.txt
Normal file
1907
source/ldap_server/devdocs/rfc4513.txt
Normal file
File diff suppressed because it is too large
Load Diff
843
source/ldap_server/devdocs/rfc4514.txt
Normal file
843
source/ldap_server/devdocs/rfc4514.txt
Normal file
@ -0,0 +1,843 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group K. Zeilenga, Ed.
|
||||
Request for Comments: 4514 OpenLDAP Foundation
|
||||
Obsoletes: 2253 June 2006
|
||||
Category: Standards Track
|
||||
|
||||
|
||||
Lightweight Directory Access Protocol (LDAP):
|
||||
String Representation of Distinguished Names
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
The X.500 Directory uses distinguished names (DNs) as primary keys to
|
||||
entries in the directory. This document defines the string
|
||||
representation used in the Lightweight Directory Access Protocol
|
||||
(LDAP) to transfer distinguished names. The string representation is
|
||||
designed to give a clean representation of commonly used
|
||||
distinguished names, while being able to represent any distinguished
|
||||
name.
|
||||
|
||||
1. Background and Intended Usage
|
||||
|
||||
In X.500-based directory systems [X.500], including those accessed
|
||||
using the Lightweight Directory Access Protocol (LDAP) [RFC4510],
|
||||
distinguished names (DNs) are used to unambiguously refer to
|
||||
directory entries [X.501][RFC4512].
|
||||
|
||||
The structure of a DN [X.501] is described in terms of ASN.1 [X.680].
|
||||
In the X.500 Directory Access Protocol [X.511] (and other ITU-defined
|
||||
directory protocols), DNs are encoded using the Basic Encoding Rules
|
||||
(BER) [X.690]. In LDAP, DNs are represented in the string form
|
||||
described in this document.
|
||||
|
||||
It is important to have a common format to be able to unambiguously
|
||||
represent a distinguished name. The primary goal of this
|
||||
specification is ease of encoding and decoding. A secondary goal is
|
||||
to have names that are human readable. It is not expected that LDAP
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 1]
|
||||
|
||||
RFC 4514 LDAP: Distinguished Names June 2006
|
||||
|
||||
|
||||
implementations with a human user interface would display these
|
||||
strings directly to the user, but that they would most likely be
|
||||
performing translations (such as expressing attribute type names in
|
||||
the local national language).
|
||||
|
||||
This document defines the string representation of Distinguished
|
||||
Names used in LDAP [RFC4511][RFC4517]. Section 2 details the
|
||||
RECOMMENDED algorithm for converting a DN from its ASN.1 structured
|
||||
representation to a string. Section 3 details how to convert a DN
|
||||
from a string to an ASN.1 structured representation.
|
||||
|
||||
While other documents may define other algorithms for converting a DN
|
||||
from its ASN.1 structured representation to a string, all algorithms
|
||||
MUST produce strings that adhere to the requirements of Section 3.
|
||||
|
||||
This document does not define a canonical string representation for
|
||||
DNs. Comparison of DNs for equality is to be performed in accordance
|
||||
with the distinguishedNameMatch matching rule [RFC4517].
|
||||
|
||||
This document is a integral part of the LDAP technical specification
|
||||
[RFC4510], which obsoletes the previously defined LDAP technical
|
||||
specification, RFC 3377, in its entirety. This document obsoletes
|
||||
RFC 2253. Changes since RFC 2253 are summarized in Appendix B.
|
||||
|
||||
This specification assumes familiarity with X.500 [X.500] and the
|
||||
concept of Distinguished Name [X.501][RFC4512].
|
||||
|
||||
1.1. Conventions
|
||||
|
||||
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].
|
||||
|
||||
Character names in this document use the notation for code points and
|
||||
names from the Unicode Standard [Unicode]. For example, the letter
|
||||
"a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
|
||||
|
||||
Note: a glossary of terms used in Unicode can be found in [Glossary].
|
||||
Information on the Unicode character encoding model can be found in
|
||||
[CharModel].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 2]
|
||||
|
||||
RFC 4514 LDAP: Distinguished Names June 2006
|
||||
|
||||
|
||||
2. Converting DistinguishedName from ASN.1 to a String
|
||||
|
||||
X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished
|
||||
name. The following is a variant provided for discussion purposes.
|
||||
|
||||
DistinguishedName ::= RDNSequence
|
||||
|
||||
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
|
||||
|
||||
RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
|
||||
AttributeTypeAndValue
|
||||
|
||||
AttributeTypeAndValue ::= SEQUENCE {
|
||||
type AttributeType,
|
||||
value AttributeValue }
|
||||
|
||||
This section defines the RECOMMENDED algorithm for converting a
|
||||
distinguished name from an ASN.1-structured representation to a UTF-8
|
||||
[RFC3629] encoded Unicode [Unicode] character string representation.
|
||||
Other documents may describe other algorithms for converting a
|
||||
distinguished name to a string, but only strings that conform to the
|
||||
grammar defined in Section 3 SHALL be produced by LDAP
|
||||
implementations.
|
||||
|
||||
2.1. Converting the RDNSequence
|
||||
|
||||
If the RDNSequence is an empty sequence, the result is the empty or
|
||||
zero-length string.
|
||||
|
||||
Otherwise, the output consists of the string encodings of each
|
||||
RelativeDistinguishedName in the RDNSequence (according to Section
|
||||
2.2), starting with the last element of the sequence and moving
|
||||
backwards toward the first.
|
||||
|
||||
The encodings of adjoining RelativeDistinguishedNames are separated
|
||||
by a comma (',' U+002C) character.
|
||||
|
||||
2.2. Converting RelativeDistinguishedName
|
||||
|
||||
When converting from an ASN.1 RelativeDistinguishedName to a string,
|
||||
the output consists of the string encodings of each
|
||||
AttributeTypeAndValue (according to Section 2.3), in any order.
|
||||
|
||||
Where there is a multi-valued RDN, the outputs from adjoining
|
||||
AttributeTypeAndValues are separated by a plus sign ('+' U+002B)
|
||||
character.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 3]
|
||||
|
||||
RFC 4514 LDAP: Distinguished Names June 2006
|
||||
|
||||
|
||||
2.3. Converting AttributeTypeAndValue
|
||||
|
||||
The AttributeTypeAndValue is encoded as the string representation of
|
||||
the AttributeType, followed by an equals sign ('=' U+003D) character,
|
||||
followed by the string representation of the AttributeValue. The
|
||||
encoding of the AttributeValue is given in Section 2.4.
|
||||
|
||||
If the AttributeType is defined to have a short name (descriptor)
|
||||
[RFC4512] and that short name is known to be registered [REGISTRY]
|
||||
[RFC4520] as identifying the AttributeType, that short name, a
|
||||
<descr>, is used. Otherwise the AttributeType is encoded as the
|
||||
dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER.
|
||||
The <descr> and <numericoid> are defined in [RFC4512].
|
||||
|
||||
Implementations are not expected to dynamically update their
|
||||
knowledge of registered short names. However, implementations SHOULD
|
||||
provide a mechanism to allow their knowledge of registered short
|
||||
names to be updated.
|
||||
|
||||
2.4. Converting an AttributeValue from ASN.1 to a String
|
||||
|
||||
If the AttributeType is of the dotted-decimal form, the
|
||||
AttributeValue is represented by an number sign ('#' U+0023)
|
||||
character followed by the hexadecimal encoding of each of the octets
|
||||
of the BER encoding of the X.500 AttributeValue. This form is also
|
||||
used when the syntax of the AttributeValue does not have an LDAP-
|
||||
specific ([RFC4517], Section 3.1) string encoding defined for it, or
|
||||
the LDAP-specific string encoding is not restricted to UTF-8-encoded
|
||||
Unicode characters. This form may also be used in other cases, such
|
||||
as when a reversible string representation is desired (see Section
|
||||
5.2).
|
||||
|
||||
Otherwise, if the AttributeValue is of a syntax that has a LDAP-
|
||||
specific string encoding, the value is converted first to a UTF-8-
|
||||
encoded Unicode string according to its syntax specification (see
|
||||
[RFC4517], Section 3.3, for examples). If that UTF-8-encoded Unicode
|
||||
string does not have any of the following characters that need
|
||||
escaping, then that string can be used as the string representation
|
||||
of the value.
|
||||
|
||||
- a space (' ' U+0020) or number sign ('#' U+0023) occurring at
|
||||
the beginning of the string;
|
||||
|
||||
- a space (' ' U+0020) character occurring at the end of the
|
||||
string;
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 4]
|
||||
|
||||
RFC 4514 LDAP: Distinguished Names June 2006
|
||||
|
||||
|
||||
- one of the characters '"', '+', ',', ';', '<', '>', or '\'
|
||||
(U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C,
|
||||
respectively);
|
||||
|
||||
- the null (U+0000) character.
|
||||
|
||||
Other characters may be escaped.
|
||||
|
||||
Each octet of the character to be escaped is replaced by a backslash
|
||||
and two hex digits, which form a single octet in the code of the
|
||||
character. Alternatively, if and only if the character to be escaped
|
||||
is one of
|
||||
|
||||
' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\'
|
||||
(U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
|
||||
U+003C, U+003D, U+003E, U+005C, respectively)
|
||||
|
||||
it can be prefixed by a backslash ('\' U+005C).
|
||||
|
||||
Examples of the escaping mechanism are shown in Section 4.
|
||||
|
||||
3. Parsing a String Back to a Distinguished Name
|
||||
|
||||
The string representation of Distinguished Names is restricted to
|
||||
UTF-8 [RFC3629] encoded Unicode [Unicode] characters. The structure
|
||||
of this string representation is specified using the following
|
||||
Augmented BNF [RFC4234] grammar:
|
||||
|
||||
distinguishedName = [ relativeDistinguishedName
|
||||
*( COMMA relativeDistinguishedName ) ]
|
||||
relativeDistinguishedName = attributeTypeAndValue
|
||||
*( PLUS attributeTypeAndValue )
|
||||
attributeTypeAndValue = attributeType EQUALS attributeValue
|
||||
attributeType = descr / numericoid
|
||||
attributeValue = string / hexstring
|
||||
|
||||
; The following characters are to be escaped when they appear
|
||||
; in the value to be encoded: ESC, one of <escaped>, leading
|
||||
; SHARP or SPACE, trailing SPACE, and NULL.
|
||||
string = [ ( leadchar / pair ) [ *( stringchar / pair )
|
||||
( trailchar / pair ) ] ]
|
||||
|
||||
leadchar = LUTF1 / UTFMB
|
||||
LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
|
||||
%x3D / %x3F-5B / %x5D-7F
|
||||
|
||||
trailchar = TUTF1 / UTFMB
|
||||
TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 5]
|
||||
|
||||
RFC 4514 LDAP: Distinguished Names June 2006
|
||||
|
||||
|
||||
%x3D / %x3F-5B / %x5D-7F
|
||||
|
||||
stringchar = SUTF1 / UTFMB
|
||||
SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
|
||||
%x3D / %x3F-5B / %x5D-7F
|
||||
|
||||
pair = ESC ( ESC / special / hexpair )
|
||||
special = escaped / SPACE / SHARP / EQUALS
|
||||
escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
|
||||
hexstring = SHARP 1*hexpair
|
||||
hexpair = HEX HEX
|
||||
|
||||
where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>,
|
||||
<EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>,
|
||||
<SPACE>, <SHARP>, and <UTFMB> are defined in [RFC4512].
|
||||
|
||||
Each <attributeType>, either a <descr> or a <numericoid>, refers to
|
||||
an attribute type of an attribute value assertion (AVA). The
|
||||
<attributeType> is followed by an <EQUALS> and an <attributeValue>.
|
||||
The <attributeValue> is either in <string> or <hexstring> form.
|
||||
|
||||
If in <string> form, a LDAP string representation asserted value can
|
||||
be obtained by replacing (left to right, non-recursively) each <pair>
|
||||
appearing in the <string> as follows:
|
||||
|
||||
replace <ESC><ESC> with <ESC>;
|
||||
replace <ESC><special> with <special>;
|
||||
replace <ESC><hexpair> with the octet indicated by the <hexpair>.
|
||||
|
||||
If in <hexstring> form, a BER representation can be obtained from
|
||||
converting each <hexpair> of the <hexstring> to the octet indicated
|
||||
by the <hexpair>.
|
||||
|
||||
There is one or more attribute value assertions, separated by <PLUS>,
|
||||
for a relative distinguished name.
|
||||
|
||||
There is zero or more relative distinguished names, separated by
|
||||
<COMMA>, for a distinguished name.
|
||||
|
||||
Implementations MUST recognize AttributeType name strings
|
||||
(descriptors) listed in the following table, but MAY recognize other
|
||||
name strings.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 6]
|
||||
|
||||
RFC 4514 LDAP: Distinguished Names June 2006
|
||||
|
||||
|
||||
String X.500 AttributeType
|
||||
------ --------------------------------------------
|
||||
CN commonName (2.5.4.3)
|
||||
L localityName (2.5.4.7)
|
||||
ST stateOrProvinceName (2.5.4.8)
|
||||
O organizationName (2.5.4.10)
|
||||
OU organizationalUnitName (2.5.4.11)
|
||||
C countryName (2.5.4.6)
|
||||
STREET streetAddress (2.5.4.9)
|
||||
DC domainComponent (0.9.2342.19200300.100.1.25)
|
||||
UID userId (0.9.2342.19200300.100.1.1)
|
||||
|
||||
These attribute types are described in [RFC4519].
|
||||
|
||||
Implementations MAY recognize other DN string representations.
|
||||
However, as there is no requirement that alternative DN string
|
||||
representations be recognized (and, if so, how), implementations
|
||||
SHOULD only generate DN strings in accordance with Section 2 of this
|
||||
document.
|
||||
|
||||
4. Examples
|
||||
|
||||
This notation is designed to be convenient for common forms of name.
|
||||
This section gives a few examples of distinguished names written
|
||||
using this notation. First is a name containing three relative
|
||||
distinguished names (RDNs):
|
||||
|
||||
UID=jsmith,DC=example,DC=net
|
||||
|
||||
Here is an example of a name containing three RDNs, in which the
|
||||
first RDN is multi-valued:
|
||||
|
||||
OU=Sales+CN=J. Smith,DC=example,DC=net
|
||||
|
||||
This example shows the method of escaping of a special characters
|
||||
appearing in a common name:
|
||||
|
||||
CN=James \"Jim\" Smith\, III,DC=example,DC=net
|
||||
|
||||
The following shows the method for encoding a value that contains a
|
||||
carriage return character:
|
||||
|
||||
CN=Before\0dAfter,DC=example,DC=net
|
||||
|
||||
In this RDN example, the type in the RDN is unrecognized, and the
|
||||
value is the BER encoding of an OCTET STRING containing two octets,
|
||||
0x48 and 0x69.
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 7]
|
||||
|
||||
RFC 4514 LDAP: Distinguished Names June 2006
|
||||
|
||||
|
||||
1.3.6.1.4.1.1466.0=#04024869
|
||||
|
||||
Finally, this example shows an RDN whose commonName value consists of
|
||||
5 letters:
|
||||
|
||||
Unicode Character Code UTF-8 Escaped
|
||||
------------------------------- ------ ------ --------
|
||||
LATIN CAPITAL LETTER L U+004C 0x4C L
|
||||
LATIN SMALL LETTER U U+0075 0x75 u
|
||||
LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D
|
||||
LATIN SMALL LETTER I U+0069 0x69 i
|
||||
LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87
|
||||
|
||||
This could be encoded in printable ASCII [ASCII] (useful for
|
||||
debugging purposes) as:
|
||||
|
||||
CN=Lu\C4\8Di\C4\87
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
The following security considerations are specific to the handling of
|
||||
distinguished names. LDAP security considerations are discussed in
|
||||
[RFC4511] and other documents comprising the LDAP Technical
|
||||
Specification [RFC4510].
|
||||
|
||||
5.1. Disclosure
|
||||
|
||||
Distinguished Names typically consist of descriptive information
|
||||
about the entries they name, which can be people, organizations,
|
||||
devices, or other real-world objects. This frequently includes some
|
||||
of the following kinds of information:
|
||||
|
||||
- the common name of the object (i.e., a person's full name)
|
||||
- an email or TCP/IP address
|
||||
- its physical location (country, locality, city, street address)
|
||||
- organizational attributes (such as department name or
|
||||
affiliation)
|
||||
|
||||
In some cases, such information can be considered sensitive. In many
|
||||
countries, privacy laws exist that prohibit disclosure of certain
|
||||
kinds of descriptive information (e.g., email addresses). Hence,
|
||||
server implementers are encouraged to support Directory Information
|
||||
Tree (DIT) structural rules and name forms [RFC4512], as these
|
||||
provide a mechanism for administrators to select appropriate naming
|
||||
attributes for entries. Administrators are encouraged to use
|
||||
mechanisms, access controls, and other administrative controls that
|
||||
may be available to restrict use of attributes containing sensitive
|
||||
information in naming of entries. Additionally, use of
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 8]
|
||||
|
||||
RFC 4514 LDAP: Distinguished Names June 2006
|
||||
|
||||
|
||||
authentication and data security services in LDAP [RFC4513][RFC4511]
|
||||
should be considered.
|
||||
|
||||
5.2. Use of Distinguished Names in Security Applications
|
||||
|
||||
The transformations of an AttributeValue value from its X.501 form to
|
||||
an LDAP string representation are not always reversible back to the
|
||||
same BER (Basic Encoding Rules) or DER (Distinguished Encoding Rules)
|
||||
form. An example of a situation that requires the DER form of a
|
||||
distinguished name is the verification of an X.509 certificate.
|
||||
|
||||
For example, a distinguished name consisting of one RDN with one AVA,
|
||||
in which the type is commonName and the value is of the TeletexString
|
||||
choice with the letters 'Sam', would be represented in LDAP as the
|
||||
string <CN=Sam>. Another distinguished name in which the value is
|
||||
still 'Sam', but is of the PrintableString choice, would have the
|
||||
same representation <CN=Sam>.
|
||||
|
||||
Applications that require the reconstruction of the DER form of the
|
||||
value SHOULD NOT use the string representation of attribute syntaxes
|
||||
when converting a distinguished name to the LDAP format. Instead,
|
||||
they SHOULD use the hexadecimal form prefixed by the number sign ('#'
|
||||
U+0023) as described in the first paragraph of Section 2.4.
|
||||
|
||||
6. Acknowledgements
|
||||
|
||||
This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and
|
||||
Steve Kille. RFC 2253 was a product of the IETF ASID Working Group.
|
||||
|
||||
This document is a product of the IETF LDAPBIS Working Group.
|
||||
|
||||
7. References
|
||||
|
||||
7.1. Normative References
|
||||
|
||||
[REGISTRY] IANA, Object Identifier Descriptors Registry,
|
||||
<http://www.iana.org/assignments/ldap-parameters>.
|
||||
|
||||
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
|
||||
3.2.0" is defined by "The Unicode Standard, Version
|
||||
3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
|
||||
61633-5), as amended by the "Unicode Standard Annex
|
||||
#27: Unicode 3.1"
|
||||
(http://www.unicode.org/reports/tr27/) and by the
|
||||
"Unicode Standard Annex #28: Unicode 3.2"
|
||||
(http://www.unicode.org/reports/tr28/).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 9]
|
||||
|
||||
RFC 4514 LDAP: Distinguished Names June 2006
|
||||
|
||||
|
||||
[X.501] International Telecommunication Union -
|
||||
Telecommunication Standardization Sector, "The
|
||||
Directory -- Models," X.501(1993) (also ISO/IEC 9594-
|
||||
2:1994).
|
||||
|
||||
[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).
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
|
||||
10646", STD 63, RFC 3629, November 2003.
|
||||
|
||||
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
||||
Specifications: ABNF", RFC 4234, October 2005.
|
||||
|
||||
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
|
||||
Protocol (LDAP): Technical Specification Road Map", RFC
|
||||
4510, June 2006.
|
||||
|
||||
[RFC4511] Sermersheim, J., Ed., "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., Ed., "Lightweight Directory Access
|
||||
Protocol (LDAP): Authentication Methods and Security
|
||||
Mechanisms", RFC 4513, June 2006.
|
||||
|
||||
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
|
||||
(LDAP): Syntaxes and Matching Rules", RFC 4517, June
|
||||
2006.
|
||||
|
||||
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
|
||||
Protocol (LDAP): Schema for User Applications", RFC
|
||||
4519, June 2006.
|
||||
|
||||
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
|
||||
(IANA) Considerations for the Lightweight Directory
|
||||
Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 10]
|
||||
|
||||
RFC 4514 LDAP: Distinguished Names June 2006
|
||||
|
||||
|
||||
7.2. Informative References
|
||||
|
||||
[ASCII] Coded Character Set--7-bit American Standard Code for
|
||||
Information Interchange, ANSI X3.4-1986.
|
||||
|
||||
[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
|
||||
#17, Character Encoding Model", UTR17,
|
||||
<http://www.unicode.org/unicode/reports/tr17/>, August
|
||||
2000.
|
||||
|
||||
[Glossary] The Unicode Consortium, "Unicode Glossary",
|
||||
<http://www.unicode.org/glossary/>.
|
||||
|
||||
[X.500] International Telecommunication Union -
|
||||
Telecommunication Standardization Sector, "The
|
||||
Directory -- Overview of concepts, models and
|
||||
services," X.500(1993) (also ISO/IEC 9594-1:1994).
|
||||
|
||||
[X.511] International Telecommunication Union -
|
||||
Telecommunication Standardization Sector, "The
|
||||
Directory: Abstract Service Definition", X.511(1993)
|
||||
(also ISO/IEC 9594-3:1993).
|
||||
|
||||
[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).
|
||||
|
||||
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
|
||||
Technical Specification", RFC 2849, June 2000.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 11]
|
||||
|
||||
RFC 4514 LDAP: Distinguished Names June 2006
|
||||
|
||||
|
||||
Appendix A. Presentation Issues
|
||||
|
||||
This appendix is provided for informational purposes only; it is not
|
||||
a normative part of this specification.
|
||||
|
||||
The string representation described in this document is not intended
|
||||
to be presented to humans without translation. However, at times it
|
||||
may be desirable to present non-translated DN strings to users. This
|
||||
section discusses presentation issues associated with non-translated
|
||||
DN strings. Issues with presentation of translated DN strings are
|
||||
not discussed in this appendix. Transcoding issues are also not
|
||||
discussed in this appendix.
|
||||
|
||||
This appendix provides guidance for applications presenting DN
|
||||
strings to users. This section is not comprehensive; it does not
|
||||
discuss all presentation issues that implementers may face.
|
||||
|
||||
Not all user interfaces are capable of displaying the full set of
|
||||
Unicode characters. Some Unicode characters are not displayable.
|
||||
|
||||
It is recommended that human interfaces use the optional hex pair
|
||||
escaping mechanism (Section 2.3) to produce a string representation
|
||||
suitable for display to the user. For example, an application can
|
||||
generate a DN string for display that escapes all non-printable
|
||||
characters appearing in the AttributeValue's string representation
|
||||
(as demonstrated in the final example of Section 4).
|
||||
|
||||
When a DN string is displayed in free-form text, it is often
|
||||
necessary to distinguish the DN string from surrounding text. While
|
||||
this is often done with whitespace (as demonstrated in Section 4), it
|
||||
is noted that DN strings may end with whitespace. Careful readers of
|
||||
Section 3 will note that the characters '<' (U+003C) and '>' (U+003E)
|
||||
may only appear in the DN string if escaped. These characters are
|
||||
intended to be used in free-form text to distinguish a DN string from
|
||||
surrounding text. For example, <CN=Sam\ > distinguishes the string
|
||||
representation of the DN composed of one RDN consisting of the AVA
|
||||
(the commonName (CN) value 'Sam ') from the surrounding text. It
|
||||
should be noted to the user that the wrapping '<' and '>' characters
|
||||
are not part of the DN string.
|
||||
|
||||
DN strings can be quite long. It is often desirable to line-wrap
|
||||
overly long DN strings in presentations. Line wrapping should be
|
||||
done by inserting whitespace after the RDN separator character or, if
|
||||
necessary, after the AVA separator character. It should be noted to
|
||||
the user that the inserted whitespace is not part of the DN string
|
||||
and is to be removed before use in LDAP. For example, the following
|
||||
DN string is long:
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 12]
|
||||
|
||||
RFC 4514 LDAP: Distinguished Names June 2006
|
||||
|
||||
|
||||
CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
|
||||
O=OpenLDAP Foundation,ST=California,C=US
|
||||
|
||||
So it has been line-wrapped for readability. The extra whitespace is
|
||||
to be removed before the DN string is used in LDAP.
|
||||
|
||||
Inserting whitespace is not advised because it may not be obvious to
|
||||
the user which whitespace is part of the DN string and which
|
||||
whitespace was added for readability.
|
||||
|
||||
Another alternative is to use the LDAP Data Interchange Format (LDIF)
|
||||
[RFC2849]. For example:
|
||||
|
||||
# This entry has a long DN...
|
||||
dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
|
||||
O=OpenLDAP Foundation,ST=California,C=US
|
||||
CN: Kurt D. Zeilenga
|
||||
SN: Zeilenga
|
||||
objectClass: person
|
||||
|
||||
Appendix B. Changes Made since RFC 2253
|
||||
|
||||
This appendix is provided for informational purposes only, it is not
|
||||
a normative part of this specification.
|
||||
|
||||
The following substantive changes were made to RFC 2253:
|
||||
|
||||
- Removed IESG Note. The IESG Note has been addressed.
|
||||
- Replaced all references to ISO 10646-1 with [Unicode].
|
||||
- Clarified (in Section 1) that this document does not define a
|
||||
canonical string representation.
|
||||
- Clarified that Section 2 describes the RECOMMENDED encoding
|
||||
algorithm and that alternative algorithms are allowed. Some
|
||||
encoding options described in RFC 2253 are now treated as
|
||||
alternative algorithms in this specification.
|
||||
- Revised specification (in Section 2) to allow short names of any
|
||||
registered attribute type to appear in string representations of
|
||||
DNs instead of being restricted to a "published table". Removed
|
||||
"as an example" language. Added statement (in Section 3)
|
||||
allowing recognition of additional names but require recognition
|
||||
of those names in the published table. The table now appears in
|
||||
Section 3.
|
||||
- Removed specification of additional requirements for LDAPv2
|
||||
implementations which also support LDAPv3 (RFC 2253, Section 4)
|
||||
as LDAPv2 is now Historic.
|
||||
- Allowed recognition of alternative string representations.
|
||||
- Updated Section 2.4 to allow hex pair escaping of all characters
|
||||
and clarified escaping for when multiple octet UTF-8 encodings
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 13]
|
||||
|
||||
RFC 4514 LDAP: Distinguished Names June 2006
|
||||
|
||||
|
||||
are present. Indicated that null (U+0000) character is to be
|
||||
escaped. Indicated that equals sign ('=' U+003D) character may
|
||||
be escaped as '\='.
|
||||
- Rewrote Section 3 to use ABNF as defined in RFC 4234.
|
||||
- Updated the Section 3 ABNF. Changes include:
|
||||
+ allowed AttributeType short names of length 1 (e.g., 'L'),
|
||||
+ used more restrictive <oid> production in AttributeTypes,
|
||||
+ did not require escaping of equals sign ('=' U+003D)
|
||||
characters,
|
||||
+ did not require escaping of non-leading number sign ('#'
|
||||
U+0023) characters,
|
||||
+ allowed space (' ' U+0020) to be escaped as '\ ',
|
||||
+ required hex escaping of null (U+0000) characters, and
|
||||
+ removed LDAPv2-only constructs.
|
||||
- Updated Section 3 to describe how to parse elements of the
|
||||
grammar.
|
||||
- Rewrote examples.
|
||||
- Added reference to documentations containing general LDAP
|
||||
security considerations.
|
||||
- Added discussion of presentation issues (Appendix A).
|
||||
- Added this appendix.
|
||||
|
||||
In addition, numerous editorial changes were made.
|
||||
|
||||
Editor's Address
|
||||
|
||||
Kurt D. Zeilenga
|
||||
OpenLDAP Foundation
|
||||
|
||||
EMail: Kurt@OpenLDAP.org
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 14]
|
||||
|
||||
RFC 4514 LDAP: Distinguished Names June 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights 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; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 15]
|
||||
|
||||
675
source/ldap_server/devdocs/rfc4515.txt
Normal file
675
source/ldap_server/devdocs/rfc4515.txt
Normal file
@ -0,0 +1,675 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group M. Smith, Ed.
|
||||
Request for Comments: 4515 Pearl Crescent, LLC
|
||||
Obsoletes: 2254 T. Howes
|
||||
Category: Standards Track Opsware, Inc.
|
||||
June 2006
|
||||
|
||||
|
||||
Lightweight Directory Access Protocol (LDAP):
|
||||
String Representation of Search Filters
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
Lightweight Directory Access Protocol (LDAP) search filters are
|
||||
transmitted in the LDAP protocol using a binary representation that
|
||||
is appropriate for use on the network. This document defines a
|
||||
human-readable string representation of LDAP search filters that is
|
||||
appropriate for use in LDAP URLs (RFC 4516) and in other
|
||||
applications.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................2
|
||||
2. LDAP Search Filter Definition ...................................2
|
||||
3. String Search Filter Definition .................................3
|
||||
4. Examples ........................................................5
|
||||
5. Security Considerations .........................................7
|
||||
6. Normative References ............................................7
|
||||
7. Informative References ..........................................8
|
||||
8. Acknowledgements ................................................8
|
||||
Appendix A: Changes Since RFC 2254 .................................9
|
||||
A.1. Technical Changes ..........................................9
|
||||
A.2. Editorial Changes ..........................................9
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Smith and Howes Standards Track [Page 1]
|
||||
|
||||
RFC 4515 LDAP: String Representation of Search Filters June 2006
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
The Lightweight Directory Access Protocol (LDAP) [RFC4510] defines a
|
||||
network representation of a search filter transmitted to an LDAP
|
||||
server. Some applications may find it useful to have a common way of
|
||||
representing these search filters in a human-readable form; LDAP URLs
|
||||
[RFC4516] are an example of one such application. This document
|
||||
defines a human-readable string format for representing the full
|
||||
range of possible LDAP version 3 search filters, including extended
|
||||
match filters.
|
||||
|
||||
This document is a integral part of the LDAP technical specification
|
||||
[RFC4510], which obsoletes the previously defined LDAP technical
|
||||
specification, RFC 3377, in its entirety.
|
||||
|
||||
This document replaces RFC 2254. Changes to RFC 2254 are summarized
|
||||
in Appendix A.
|
||||
|
||||
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].
|
||||
|
||||
2. LDAP Search Filter Definition
|
||||
|
||||
An LDAP search filter is defined in Section 4.5.1 of [RFC4511] as
|
||||
follows:
|
||||
|
||||
Filter ::= CHOICE {
|
||||
and [0] SET SIZE (1..MAX) OF filter Filter,
|
||||
or [1] SET SIZE (1..MAX) OF filter Filter,
|
||||
not [2] Filter,
|
||||
equalityMatch [3] AttributeValueAssertion,
|
||||
substrings [4] SubstringFilter,
|
||||
greaterOrEqual [5] AttributeValueAssertion,
|
||||
lessOrEqual [6] AttributeValueAssertion,
|
||||
present [7] AttributeDescription,
|
||||
approxMatch [8] AttributeValueAssertion,
|
||||
extensibleMatch [9] MatchingRuleAssertion }
|
||||
|
||||
SubstringFilter ::= SEQUENCE {
|
||||
type AttributeDescription,
|
||||
-- initial and final can occur at most once
|
||||
substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
|
||||
initial [0] AssertionValue,
|
||||
any [1] AssertionValue,
|
||||
final [2] AssertionValue } }
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Smith and Howes Standards Track [Page 2]
|
||||
|
||||
RFC 4515 LDAP: String Representation of Search Filters June 2006
|
||||
|
||||
|
||||
AttributeValueAssertion ::= SEQUENCE {
|
||||
attributeDesc AttributeDescription,
|
||||
assertionValue AssertionValue }
|
||||
|
||||
MatchingRuleAssertion ::= SEQUENCE {
|
||||
matchingRule [1] MatchingRuleId OPTIONAL,
|
||||
type [2] AttributeDescription OPTIONAL,
|
||||
matchValue [3] AssertionValue,
|
||||
dnAttributes [4] BOOLEAN DEFAULT FALSE }
|
||||
|
||||
AttributeDescription ::= LDAPString
|
||||
-- Constrained to <attributedescription>
|
||||
-- [RFC4512]
|
||||
|
||||
AttributeValue ::= OCTET STRING
|
||||
|
||||
MatchingRuleId ::= LDAPString
|
||||
|
||||
AssertionValue ::= OCTET STRING
|
||||
|
||||
LDAPString ::= OCTET STRING -- UTF-8 encoded,
|
||||
-- [Unicode] characters
|
||||
|
||||
The AttributeDescription, as defined in [RFC4511], is a string
|
||||
representation of the attribute description that is discussed in
|
||||
[RFC4512]. The AttributeValue and AssertionValue OCTET STRING have
|
||||
the form defined in [RFC4517]. The Filter is encoded for
|
||||
transmission over a network using the Basic Encoding Rules (BER)
|
||||
defined in [X.690], with simplifications described in [RFC4511].
|
||||
|
||||
3. String Search Filter Definition
|
||||
|
||||
The string representation of an LDAP search filter is a string of
|
||||
UTF-8 [RFC3629] encoded Unicode characters [Unicode] that is defined
|
||||
by the following grammar, following the ABNF notation defined in
|
||||
[RFC4234]. The productions used that are not defined here are
|
||||
defined in Section 1.4 (Common ABNF Productions) of [RFC4512] unless
|
||||
otherwise noted. The filter format uses a prefix notation.
|
||||
|
||||
filter = LPAREN filtercomp RPAREN
|
||||
filtercomp = and / or / not / item
|
||||
and = AMPERSAND filterlist
|
||||
or = VERTBAR filterlist
|
||||
not = EXCLAMATION filter
|
||||
filterlist = 1*filter
|
||||
item = simple / present / substring / extensible
|
||||
simple = attr filtertype assertionvalue
|
||||
filtertype = equal / approx / greaterorequal / lessorequal
|
||||
|
||||
|
||||
|
||||
Smith and Howes Standards Track [Page 3]
|
||||
|
||||
RFC 4515 LDAP: String Representation of Search Filters June 2006
|
||||
|
||||
|
||||
equal = EQUALS
|
||||
approx = TILDE EQUALS
|
||||
greaterorequal = RANGLE EQUALS
|
||||
lessorequal = LANGLE EQUALS
|
||||
extensible = ( attr [dnattrs]
|
||||
[matchingrule] COLON EQUALS assertionvalue )
|
||||
/ ( [dnattrs]
|
||||
matchingrule COLON EQUALS assertionvalue )
|
||||
present = attr EQUALS ASTERISK
|
||||
substring = attr EQUALS [initial] any [final]
|
||||
initial = assertionvalue
|
||||
any = ASTERISK *(assertionvalue ASTERISK)
|
||||
final = assertionvalue
|
||||
attr = attributedescription
|
||||
; The attributedescription rule is defined in
|
||||
; Section 2.5 of [RFC4512].
|
||||
dnattrs = COLON "dn"
|
||||
matchingrule = COLON oid
|
||||
assertionvalue = valueencoding
|
||||
; The <valueencoding> rule is used to encode an <AssertionValue>
|
||||
; from Section 4.1.6 of [RFC4511].
|
||||
valueencoding = 0*(normal / escaped)
|
||||
normal = UTF1SUBSET / UTFMB
|
||||
escaped = ESC HEX HEX
|
||||
UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F
|
||||
; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
|
||||
; RPAREN, ASTERISK, and ESC.
|
||||
EXCLAMATION = %x21 ; exclamation mark ("!")
|
||||
AMPERSAND = %x26 ; ampersand (or AND symbol) ("&")
|
||||
ASTERISK = %x2A ; asterisk ("*")
|
||||
COLON = %x3A ; colon (":")
|
||||
VERTBAR = %x7C ; vertical bar (or pipe) ("|")
|
||||
TILDE = %x7E ; tilde ("~")
|
||||
|
||||
Note that although both the <substring> and <present> productions in
|
||||
the grammar above can produce the "attr=*" construct, this construct
|
||||
is used only to denote a presence filter.
|
||||
|
||||
The <valueencoding> rule ensures that the entire filter string is a
|
||||
valid UTF-8 string and provides that the octets that represent the
|
||||
ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII
|
||||
0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a
|
||||
backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits
|
||||
representing the value of the encoded octet.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Smith and Howes Standards Track [Page 4]
|
||||
|
||||
RFC 4515 LDAP: String Representation of Search Filters June 2006
|
||||
|
||||
|
||||
This simple escaping mechanism eliminates filter-parsing ambiguities
|
||||
and allows any filter that can be represented in LDAP to be
|
||||
represented as a NUL-terminated string. Other octets that are part
|
||||
of the <normal> set may be escaped using this mechanism, for example,
|
||||
non-printing ASCII characters.
|
||||
|
||||
For AssertionValues that contain UTF-8 character data, each octet of
|
||||
the character to be escaped is replaced by a backslash and two hex
|
||||
digits, which form a single octet in the code of the character. For
|
||||
example, the filter checking whether the "cn" attribute contained a
|
||||
value with the character "*" anywhere in it would be represented as
|
||||
"(cn=*\2a*)".
|
||||
|
||||
As indicated by the <valueencoding> rule, implementations MUST escape
|
||||
all octets greater than 0x7F that are not part of a valid UTF-8
|
||||
encoding sequence when they generate a string representation of a
|
||||
search filter. Implementations SHOULD accept as input strings that
|
||||
are not valid UTF-8 strings. This is necessary because RFC 2254 did
|
||||
not clearly define the term "string representation" (and in
|
||||
particular did not mention that the string representation of an LDAP
|
||||
search filter is a string of UTF-8-encoded Unicode characters).
|
||||
|
||||
4. Examples
|
||||
|
||||
This section gives a few examples of search filters written using
|
||||
this notation.
|
||||
|
||||
(cn=Babs Jensen)
|
||||
(!(cn=Tim Howes))
|
||||
(&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
|
||||
(o=univ*of*mich*)
|
||||
(seeAlso=)
|
||||
|
||||
The following examples illustrate the use of extensible matching.
|
||||
|
||||
(cn:caseExactMatch:=Fred Flintstone)
|
||||
(cn:=Betty Rubble)
|
||||
(sn:dn:2.4.6.8.10:=Barney Rubble)
|
||||
(o:dn:=Ace Industry)
|
||||
(:1.2.3:=Wilma Flintstone)
|
||||
(:DN:2.4.6.8.10:=Dino)
|
||||
|
||||
The first example shows use of the matching rule "caseExactMatch."
|
||||
|
||||
The second example demonstrates use of a MatchingRuleAssertion form
|
||||
without a matchingRule.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Smith and Howes Standards Track [Page 5]
|
||||
|
||||
RFC 4515 LDAP: String Representation of Search Filters June 2006
|
||||
|
||||
|
||||
The third example illustrates the use of the ":oid" notation to
|
||||
indicate that the matching rule identified by the OID "2.4.6.8.10"
|
||||
should be used when making comparisons, and that the attributes of an
|
||||
entry's distinguished name should be considered part of the entry
|
||||
when evaluating the match (indicated by the use of ":dn").
|
||||
|
||||
The fourth example denotes an equality match, except that DN
|
||||
components should be considered part of the entry when doing the
|
||||
match.
|
||||
|
||||
The fifth example is a filter that should be applied to any attribute
|
||||
supporting the matching rule given (since the <attr> has been
|
||||
omitted).
|
||||
|
||||
The sixth and final example is also a filter that should be applied
|
||||
to any attribute supporting the matching rule given. Attributes
|
||||
supporting the matching rule contained in the DN should also be
|
||||
considered.
|
||||
|
||||
The following examples illustrate the use of the escaping mechanism.
|
||||
|
||||
(o=Parens R Us \28for all your parenthetical needs\29)
|
||||
(cn=*\2A*)
|
||||
(filename=C:\5cMyFile)
|
||||
(bin=\00\00\00\04)
|
||||
(sn=Lu\c4\8di\c4\87)
|
||||
(1.3.6.1.4.1.1466.0=\04\02\48\69)
|
||||
|
||||
The first example shows the use of the escaping mechanism to
|
||||
represent parenthesis characters. The second shows how to represent
|
||||
a "*" in an assertion value, preventing it from being interpreted as
|
||||
a substring indicator. The third illustrates the escaping of the
|
||||
backslash character.
|
||||
|
||||
The fourth example shows a filter searching for the four-octet value
|
||||
00 00 00 04 (hex), illustrating the use of the escaping mechanism to
|
||||
represent arbitrary data, including NUL characters.
|
||||
|
||||
The fifth example illustrates the use of the escaping mechanism to
|
||||
represent various non-ASCII UTF-8 characters. Specifically, there
|
||||
are 5 characters in the <assertionvalue> portion of this example:
|
||||
LATIN CAPITAL LETTER L (U+004C), LATIN SMALL LETTER U (U+0075), LATIN
|
||||
SMALL LETTER C WITH CARON (U+010D), LATIN SMALL LETTER I (U+0069),
|
||||
and LATIN SMALL LETTER C WITH ACUTE (U+0107).
|
||||
|
||||
The sixth and final example demonstrates assertion of a BER-encoded
|
||||
value.
|
||||
|
||||
|
||||
|
||||
|
||||
Smith and Howes Standards Track [Page 6]
|
||||
|
||||
RFC 4515 LDAP: String Representation of Search Filters June 2006
|
||||
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
This memo describes a string representation of LDAP search filters.
|
||||
While the representation itself has no known security implications,
|
||||
LDAP search filters do. They are interpreted by LDAP servers to
|
||||
select entries from which data is retrieved. LDAP servers should
|
||||
take care to protect the data they maintain from unauthorized access.
|
||||
|
||||
Please refer to the Security Considerations sections of [RFC4511] and
|
||||
[RFC4513] for more information.
|
||||
|
||||
6. Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
|
||||
10646", STD 63, RFC 3629, November 2003.
|
||||
|
||||
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
||||
Specifications: ABNF", RFC 4234, October 2005.
|
||||
|
||||
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
|
||||
(LDAP): Technical Specification Road Map", RFC 4510, June
|
||||
2006.
|
||||
|
||||
[RFC4511] Sermersheim, J., Ed., "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., Ed., "Lightweight Directory Access Protocol
|
||||
(LDAP): Authentication Methods and Security Mechanisms",
|
||||
RFC 4513, June 2006.
|
||||
|
||||
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
|
||||
(LDAP): Syntaxes and Matching Rules", RFC 4517, June
|
||||
2006.
|
||||
|
||||
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
|
||||
3.2.0" is defined by "The Unicode Standard, Version 3.0"
|
||||
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
|
||||
as amended by the "Unicode Standard Annex #27: Unicode
|
||||
3.1" (http://www.unicode.org/reports/tr27/) and by the
|
||||
"Unicode Standard Annex #28: Unicode 3.2."
|
||||
|
||||
|
||||
|
||||
|
||||
Smith and Howes Standards Track [Page 7]
|
||||
|
||||
RFC 4515 LDAP: String Representation of Search Filters June 2006
|
||||
|
||||
|
||||
7. Informative References
|
||||
|
||||
[RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory
|
||||
Access Protocol (LDAP): Uniform Resource Locator", RFC
|
||||
4516, June 2006.
|
||||
|
||||
[X.690] Specification of ASN.1 encoding rules: Basic, Canonical,
|
||||
and Distinguished Encoding Rules, ITU-T Recommendation
|
||||
X.690, 1994.
|
||||
|
||||
8. Acknowledgements
|
||||
|
||||
This document replaces RFC 2254 by Tim Howes. RFC 2254 was a product
|
||||
of the IETF ASID Working Group.
|
||||
|
||||
Changes included in this revised specification are based upon
|
||||
discussions among the authors, discussions within the LDAP (v3)
|
||||
Revision Working Group (ldapbis), and discussions within other IETF
|
||||
Working Groups. The contributions of individuals in these working
|
||||
groups is gratefully acknowledged.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Smith and Howes Standards Track [Page 8]
|
||||
|
||||
RFC 4515 LDAP: String Representation of Search Filters June 2006
|
||||
|
||||
|
||||
Appendix A: Changes Since RFC 2254
|
||||
|
||||
A.1. Technical Changes
|
||||
|
||||
Replaced [ISO 10646] reference with [Unicode].
|
||||
|
||||
The following technical changes were made to the contents of the
|
||||
"String Search Filter Definition" section:
|
||||
|
||||
Added statement that the string representation is a string of UTF-8-
|
||||
encoded Unicode characters.
|
||||
|
||||
Revised all of the ABNF to use common productions from [RFC4512].
|
||||
|
||||
Replaced the "value" rule with a new "assertionvalue" rule within the
|
||||
"simple", "extensible", and "substring" ("initial", "any", and
|
||||
"final") rules. This matches a change made in [RFC4517].
|
||||
|
||||
Added "(" and ")" around the components of the <extensible>
|
||||
subproductions for clarity.
|
||||
|
||||
Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more
|
||||
precisely reference productions from the [RFC4512] and [RFC4511]
|
||||
documents.
|
||||
|
||||
"String Search Filter Definition" section: replaced "greater" and
|
||||
"less" with "greaterorequal" and "lessorequal" to avoid confusion.
|
||||
|
||||
Introduced the "valueencoding" and associated "normal" and "escaped"
|
||||
rules to reduce the dependence on descriptive text. The "normal"
|
||||
production restricts filter strings to valid UTF-8 sequences.
|
||||
|
||||
Added a statement about expected behavior in light of RFC 2254's lack
|
||||
of a clear definition of "string representation."
|
||||
|
||||
A.2. Editorial Changes
|
||||
|
||||
Changed document title to include "LDAP:" prefix.
|
||||
|
||||
IESG Note: removed note about lack of satisfactory mandatory
|
||||
authentication mechanisms.
|
||||
|
||||
Header and "Authors' Addresses" sections: added Mark Smith as the
|
||||
document editor and updated affiliation and contact information.
|
||||
|
||||
"Table of Contents" and "Intellectual Property" sections: added.
|
||||
|
||||
Copyright: updated per latest IETF guidelines.
|
||||
|
||||
|
||||
|
||||
Smith and Howes Standards Track [Page 9]
|
||||
|
||||
RFC 4515 LDAP: String Representation of Search Filters June 2006
|
||||
|
||||
|
||||
"Abstract" section: separated from introductory material.
|
||||
|
||||
"Introduction" section: new section; separated from the Abstract.
|
||||
Updated second paragraph to indicate that RFC 2254 is replaced by
|
||||
this document (instead of RFC 1960). Added reference to the
|
||||
[RFC4510] document.
|
||||
|
||||
"LDAP Search Filter Definition" section: made corrections to the LDAP
|
||||
search filter ABNF so it matches that used in [RFC4511].
|
||||
|
||||
Clarified the definition of 'value' (now 'assertionvalue') to take
|
||||
into account the fact that it is not precisely an AttributeAssertion
|
||||
from [RFC4511] Section 4.1.6 (special handling is required for some
|
||||
characters). Added a note that each octet of a character to be
|
||||
escaped is replaced by a backslash and two hex digits, which
|
||||
represent a single octet.
|
||||
|
||||
"Examples" section: added four additional examples: (seeAlso=),
|
||||
(cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and
|
||||
(1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a
|
||||
value" with "an assertion value". Corrected the description of this
|
||||
example: (sn:dn:2.4.6.8.10:=Barney Rubble). Replaced the numeric OID
|
||||
in the first extensible match example with "caseExactMatch" to
|
||||
demonstrate use of the descriptive form. Used "DN" (uppercase) in
|
||||
the last extensible match example to remind the reader to treat the
|
||||
<dnattrs> production as case insensitive. Reworded the description
|
||||
of the fourth escaping mechanism example to avoid making assumptions
|
||||
about byte order. Added text to the fifth escaping mechanism example
|
||||
to spell out what the non-ASCII characters are in Unicode terms.
|
||||
|
||||
"Security Considerations" section: added references to [RFC4511] and
|
||||
[RFC4513].
|
||||
|
||||
"Normative References" section: renamed from "References" per new RFC
|
||||
guidelines. Changed from [1] style to [RFC4511] style throughout the
|
||||
document. Added entries for [Unicode], [RFC2119], [RFC4513],
|
||||
[RFC4512], and [RFC4510] and updated the UTF-8 reference. Replaced
|
||||
RFC 822 reference with a reference to RFC 4234.
|
||||
|
||||
"Informative References" section: (new section) moved [X.690] to this
|
||||
section. Added a reference to [RFC4516].
|
||||
|
||||
"Acknowledgements" section: added.
|
||||
|
||||
"Appendix A: Changes Since RFC 2254" section: added.
|
||||
|
||||
Surrounded the names of all ABNF productions with "<" and ">" where
|
||||
they are used in descriptive text.
|
||||
|
||||
|
||||
|
||||
Smith and Howes Standards Track [Page 10]
|
||||
|
||||
RFC 4515 LDAP: String Representation of Search Filters June 2006
|
||||
|
||||
|
||||
Replaced all occurrences of "LDAPv3" with "LDAP."
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Mark Smith, Editor
|
||||
Pearl Crescent, LLC
|
||||
447 Marlpool Dr.
|
||||
Saline, MI 48176
|
||||
USA
|
||||
|
||||
Phone: +1 734 944-2856
|
||||
EMail: mcs@pearlcrescent.com
|
||||
|
||||
|
||||
Tim Howes
|
||||
Opsware, Inc.
|
||||
599 N. Mathilda Ave.
|
||||
Sunnyvale, CA 94085
|
||||
USA
|
||||
|
||||
Phone: +1 408 744-7509
|
||||
EMail: howes@opsware.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Smith and Howes Standards Track [Page 11]
|
||||
|
||||
RFC 4515 LDAP: String Representation of Search Filters June 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights 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; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Smith and Howes Standards Track [Page 12]
|
||||
|
||||
843
source/ldap_server/devdocs/rfc4516.txt
Normal file
843
source/ldap_server/devdocs/rfc4516.txt
Normal file
@ -0,0 +1,843 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group M. Smith, Ed.
|
||||
Request for Comments: 4516 Pearl Crescent, LLC
|
||||
Obsoletes: 2255 T. Howes
|
||||
Category: Standards Track Opsware, Inc.
|
||||
June 2006
|
||||
|
||||
|
||||
Lightweight Directory Access Protocol (LDAP):
|
||||
Uniform Resource Locator
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes a format for a Lightweight Directory Access
|
||||
Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL
|
||||
describes an LDAP search operation that is used to retrieve
|
||||
information from an LDAP directory, or, in the context of an LDAP
|
||||
referral or reference, an LDAP URL describes a service where an LDAP
|
||||
operation may be progressed.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................2
|
||||
2. URL Definition ..................................................2
|
||||
2.1. Percent-Encoding ...........................................4
|
||||
3. Defaults for Fields of the LDAP URL .............................5
|
||||
4. Examples ........................................................6
|
||||
5. Security Considerations .........................................8
|
||||
6. Normative References ............................................9
|
||||
7. Informative References .........................................10
|
||||
8. Acknowledgements ...............................................10
|
||||
Appendix A: Changes Since RFC 2255 ................................11
|
||||
A.1. Technical Changes .........................................11
|
||||
A.2. Editorial Changes .........................................11
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Smith & Howes Standards Track [Page 1]
|
||||
|
||||
RFC 4516 LDAP: Uniform Resource Locator June 2006
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
LDAP is the Lightweight Directory Access Protocol [RFC4510]. This
|
||||
document specifies the LDAP URL format for version 3 of LDAP and
|
||||
clarifies how LDAP URLs are resolved. This document also defines an
|
||||
extension mechanism for LDAP URLs. This mechanism may be used to
|
||||
provide access to new LDAP extensions.
|
||||
|
||||
Note that not all the parameters of the LDAP search operation
|
||||
described in [RFC4511] can be expressed using the format defined in
|
||||
this document. Note also that URLs may be used to represent
|
||||
reference knowledge, including that for non-search operations.
|
||||
|
||||
This document is an integral part of the LDAP technical specification
|
||||
[RFC4510], which obsoletes the previously defined LDAP technical
|
||||
specification, RFC 3377, in its entirety.
|
||||
|
||||
This document replaces RFC 2255. See Appendix A for a list of
|
||||
changes relative to RFC 2255.
|
||||
|
||||
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].
|
||||
|
||||
2. URL Definition
|
||||
|
||||
An LDAP URL begins with the protocol prefix "ldap" and is defined by
|
||||
the following grammar, following the ABNF notation defined in
|
||||
[RFC4234].
|
||||
|
||||
ldapurl = scheme COLON SLASH SLASH [host [COLON port]]
|
||||
[SLASH dn [QUESTION [attributes]
|
||||
[QUESTION [scope] [QUESTION [filter]
|
||||
[QUESTION extensions]]]]]
|
||||
; <host> and <port> are defined
|
||||
; in Sections 3.2.2 and 3.2.3
|
||||
; of [RFC3986].
|
||||
; <filter> is from Section 3 of
|
||||
; [RFC4515], subject to the
|
||||
; provisions of the
|
||||
; "Percent-Encoding" section
|
||||
; below.
|
||||
|
||||
scheme = "ldap"
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Smith & Howes Standards Track [Page 2]
|
||||
|
||||
RFC 4516 LDAP: Uniform Resource Locator June 2006
|
||||
|
||||
|
||||
dn = distinguishedName ; From Section 3 of [RFC4514],
|
||||
; subject to the provisions of
|
||||
; the "Percent-Encoding"
|
||||
; section below.
|
||||
|
||||
attributes = attrdesc *(COMMA attrdesc)
|
||||
attrdesc = selector *(COMMA selector)
|
||||
selector = attributeSelector ; From Section 4.5.1 of
|
||||
; [RFC4511], subject to the
|
||||
; provisions of the
|
||||
; "Percent-Encoding" section
|
||||
; below.
|
||||
|
||||
scope = "base" / "one" / "sub"
|
||||
extensions = extension *(COMMA extension)
|
||||
extension = [EXCLAMATION] extype [EQUALS exvalue]
|
||||
extype = oid ; From section 1.4 of [RFC4512].
|
||||
|
||||
exvalue = LDAPString ; From section 4.1.2 of
|
||||
; [RFC4511], subject to the
|
||||
; provisions of the
|
||||
; "Percent-Encoding" section
|
||||
; below.
|
||||
|
||||
EXCLAMATION = %x21 ; exclamation mark ("!")
|
||||
SLASH = %x2F ; forward slash ("/")
|
||||
COLON = %x3A ; colon (":")
|
||||
QUESTION = %x3F ; question mark ("?")
|
||||
|
||||
The "ldap" prefix indicates an entry or entries accessible from the
|
||||
LDAP server running on the given hostname at the given portnumber.
|
||||
Note that the <host> may contain literal IPv6 addresses as specified
|
||||
in Section 3.2.2 of [RFC3986].
|
||||
|
||||
The <dn> is an LDAP Distinguished Name using the string format
|
||||
described in [RFC4514]. It identifies the base object of the LDAP
|
||||
search or the target of a non-search operation.
|
||||
|
||||
The <attributes> construct is used to indicate which attributes
|
||||
should be returned from the entry or entries.
|
||||
|
||||
The <scope> construct is used to specify the scope of the search to
|
||||
perform in the given LDAP server. The allowable scopes are "base"
|
||||
for a base object search, "one" for a one-level search, or "sub" for
|
||||
a subtree search.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Smith & Howes Standards Track [Page 3]
|
||||
|
||||
RFC 4516 LDAP: Uniform Resource Locator June 2006
|
||||
|
||||
|
||||
The <filter> is used to specify the search filter to apply to entries
|
||||
within the specified scope during the search. It has the format
|
||||
specified in [RFC4515].
|
||||
|
||||
The <extensions> construct provides the LDAP URL with an
|
||||
extensibility mechanism, allowing the capabilities of the URL to be
|
||||
extended in the future. Extensions are a simple comma-separated list
|
||||
of type=value pairs, where the =value portion MAY be omitted for
|
||||
options not requiring it. Each type=value pair is a separate
|
||||
extension. These LDAP URL extensions are not necessarily related to
|
||||
any of the LDAP extension mechanisms. Extensions may be supported or
|
||||
unsupported by the client resolving the URL. An extension prefixed
|
||||
with a '!' character (ASCII 0x21) is critical. An extension not
|
||||
prefixed with a '!' character is non-critical.
|
||||
|
||||
If an LDAP URL extension is implemented (that is, if the
|
||||
implementation understands it and is able to use it), the
|
||||
implementation MUST make use of it. If an extension is not
|
||||
implemented and is marked critical, the implementation MUST NOT
|
||||
process the URL. If an extension is not implemented and is not
|
||||
marked critical, the implementation MUST ignore the extension.
|
||||
|
||||
The extension type (<extype>) MAY be specified using the numeric OID
|
||||
<numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form
|
||||
(e.g., myLDAPURLExtension). Use of the <descr> form SHOULD be
|
||||
restricted to registered object identifier descriptive names. See
|
||||
[RFC4520] for registration details and usage guidelines for
|
||||
descriptive names.
|
||||
|
||||
No LDAP URL extensions are defined in this document. Other documents
|
||||
or a future version of this document MAY define one or more
|
||||
extensions.
|
||||
|
||||
2.1. Percent-Encoding
|
||||
|
||||
A generated LDAP URL MUST consist only of the restricted set of
|
||||
characters included in one of the following three productions defined
|
||||
in [RFC3986]:
|
||||
|
||||
<reserved>
|
||||
<unreserved>
|
||||
<pct-encoded>
|
||||
|
||||
Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as
|
||||
input. An octet MUST be encoded using the percent-encoding mechanism
|
||||
described in section 2.1 of [RFC3986] in any of these situations:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Smith & Howes Standards Track [Page 4]
|
||||
|
||||
RFC 4516 LDAP: Uniform Resource Locator June 2006
|
||||
|
||||
|
||||
The octet is not in the reserved set defined in section 2.2 of
|
||||
[RFC3986] or in the unreserved set defined in section 2.3 of
|
||||
[RFC3986].
|
||||
|
||||
It is the single Reserved character '?' and occurs inside a <dn>,
|
||||
<filter>, or other element of an LDAP URL.
|
||||
|
||||
It is a comma character ',' that occurs inside an <exvalue>.
|
||||
|
||||
Note that before the percent-encoding mechanism is applied, the
|
||||
extensions component of the LDAP URL may contain one or more null
|
||||
(zero) bytes. No other component may.
|
||||
|
||||
3. Defaults for Fields of the LDAP URL
|
||||
|
||||
Some fields of the LDAP URL are optional, as described above. In the
|
||||
absence of any other specification, the following general defaults
|
||||
SHOULD be used when a field is absent. Note that other documents MAY
|
||||
specify different defaulting rules; for example, section 4.1.10 of
|
||||
[RFC4511] specifies a different rule for determining the correct DN
|
||||
to use when it is absent in an LDAP URL that is returned as a
|
||||
referral.
|
||||
|
||||
<host>
|
||||
If no <host> is given, the client must have some a priori
|
||||
knowledge of an appropriate LDAP server to contact.
|
||||
|
||||
<port>
|
||||
The default LDAP port is TCP port 389.
|
||||
|
||||
<dn>
|
||||
If no <dn> is given, the default is the zero-length DN, "".
|
||||
|
||||
<attributes>
|
||||
If the <attributes> part is omitted, all user attributes of the
|
||||
entry or entries should be requested (e.g., by setting the
|
||||
attributes field AttributeDescriptionList in the LDAP search
|
||||
request to a NULL list, or by using the special <alluserattrs>
|
||||
selector "*").
|
||||
|
||||
<scope>
|
||||
If <scope> is omitted, a <scope> of "base" is assumed.
|
||||
|
||||
<filter>
|
||||
If <filter> is omitted, a filter of "(objectClass=*)" is assumed.
|
||||
|
||||
<extensions>
|
||||
If <extensions> is omitted, no extensions are assumed.
|
||||
|
||||
|
||||
|
||||
Smith & Howes Standards Track [Page 5]
|
||||
|
||||
RFC 4516 LDAP: Uniform Resource Locator June 2006
|
||||
|
||||
|
||||
4. Examples
|
||||
|
||||
The following are some example LDAP URLs that use the format defined
|
||||
above. The first example is an LDAP URL referring to the University
|
||||
of Michigan entry, available from an LDAP server of the client's
|
||||
choosing:
|
||||
|
||||
ldap:///o=University%20of%20Michigan,c=US
|
||||
|
||||
The next example is an LDAP URL referring to the University of
|
||||
Michigan entry in a particular ldap server:
|
||||
|
||||
ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
|
||||
|
||||
Both of these URLs correspond to a base object search of the
|
||||
"o=University of Michigan,c=US" entry using a filter of
|
||||
"(objectclass=*)", requesting all attributes.
|
||||
|
||||
The next example is an LDAP URL referring to only the postalAddress
|
||||
attribute of the University of Michigan entry:
|
||||
|
||||
ldap://ldap1.example.net/o=University%20of%20Michigan,
|
||||
c=US?postalAddress
|
||||
|
||||
The corresponding LDAP search operation is the same as in the
|
||||
previous example, except that only the postalAddress attribute is
|
||||
requested.
|
||||
|
||||
The next example is an LDAP URL referring to the set of entries found
|
||||
by querying the given LDAP server on port 6666 and doing a subtree
|
||||
search of the University of Michigan for any entry with a common name
|
||||
of "Babs Jensen", retrieving all attributes:
|
||||
|
||||
ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
|
||||
c=US??sub?(cn=Babs%20Jensen)
|
||||
|
||||
The next example is an LDAP URL referring to all children of the c=GB
|
||||
entry:
|
||||
|
||||
LDAP://ldap1.example.com/c=GB?objectClass?ONE
|
||||
|
||||
The objectClass attribute is requested to be returned along with the
|
||||
entries, and the default filter of "(objectclass=*)" is used.
|
||||
|
||||
The next example is an LDAP URL to retrieve the mail attribute for
|
||||
the LDAP entry named "o=Question?,c=US", illustrating the use of the
|
||||
percent-encoding mechanism on the reserved character '?'.
|
||||
|
||||
|
||||
|
||||
|
||||
Smith & Howes Standards Track [Page 6]
|
||||
|
||||
RFC 4516 LDAP: Uniform Resource Locator June 2006
|
||||
|
||||
|
||||
ldap://ldap2.example.com/o=Question%3f,c=US?mail
|
||||
|
||||
The next example (which is broken into two lines for readability)
|
||||
illustrates the interaction between the LDAP string representation of
|
||||
the filters-quoting mechanism and the URL-quoting mechanisms.
|
||||
|
||||
ldap://ldap3.example.com/o=Babsco,c=US
|
||||
???(four-octet=%5c00%5c00%5c00%5c04)
|
||||
|
||||
The filter in this example uses the LDAP escaping mechanism of \ to
|
||||
encode three zero or null bytes in the value. In LDAP, the filter
|
||||
would be written as (four-octet=\00\00\00\04). Because the \
|
||||
character must be escaped in a URL, the \s are percent-encoded as %5c
|
||||
(or %5C) in the URL encoding.
|
||||
|
||||
The next example illustrates the interaction between the LDAP string
|
||||
representation of the DNs-quoting mechanism and URL-quoting
|
||||
mechanisms.
|
||||
|
||||
ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
|
||||
|
||||
The DN encoded in the above URL is:
|
||||
|
||||
o=An Example\2C Inc.,c=US
|
||||
|
||||
That is, the left-most RDN value is:
|
||||
|
||||
An Example, Inc.
|
||||
|
||||
The following three URLs are equivalent, assuming that the defaulting
|
||||
rules specified in Section 3 of this document are used:
|
||||
|
||||
ldap://ldap.example.net
|
||||
ldap://ldap.example.net/
|
||||
ldap://ldap.example.net/?
|
||||
|
||||
These three URLs point to the root DSE on the ldap.example.net
|
||||
server.
|
||||
|
||||
The final two examples show use of a hypothetical, experimental bind
|
||||
name extension (the value associated with the extension is an LDAP
|
||||
DN).
|
||||
|
||||
ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
|
||||
ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Smith & Howes Standards Track [Page 7]
|
||||
|
||||
RFC 4516 LDAP: Uniform Resource Locator June 2006
|
||||
|
||||
|
||||
The two URLs are the same, except that the second one marks the
|
||||
e-bindname extension as critical. Notice the use of the percent-
|
||||
encoding mechanism to encode the commas within the distinguished name
|
||||
value in the e-bindname extension.
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
The general URL security considerations discussed in [RFC3986] are
|
||||
relevant for LDAP URLs.
|
||||
|
||||
The use of security mechanisms when processing LDAP URLs requires
|
||||
particular care, since clients may encounter many different servers
|
||||
via URLs, and since URLs are likely to be processed automatically,
|
||||
without user intervention. A client SHOULD have a user-configurable
|
||||
policy that controls which servers the client will establish LDAP
|
||||
sessions with and with which security mechanisms, and SHOULD NOT
|
||||
establish LDAP sessions that are inconsistent with this policy. If a
|
||||
client chooses to reuse an existing LDAP session when resolving one
|
||||
or more LDAP URLs, it MUST ensure that the session is compatible with
|
||||
the URL and that no security policies are violated.
|
||||
|
||||
Sending authentication information, no matter the mechanism, may
|
||||
violate a user's privacy requirements. In the absence of specific
|
||||
policy permitting authentication information to be sent to a server,
|
||||
a client should use an anonymous LDAP session. (Note that clients
|
||||
conforming to previous LDAP URL specifications, where all LDAP
|
||||
sessions are anonymous and unprotected, are consistent with this
|
||||
specification; they simply have the default security policy.) Simply
|
||||
opening a transport connection to another server may violate some
|
||||
users' privacy requirements, so clients should provide the user with
|
||||
a way to control URL processing.
|
||||
|
||||
Some authentication methods, in particular, reusable passwords sent
|
||||
to the server, may reveal easily-abused information to the remote
|
||||
server or to eavesdroppers in transit and should not be used in URL
|
||||
processing unless they are explicitly permitted by policy.
|
||||
Confirmation by the human user of the use of authentication
|
||||
information is appropriate in many circumstances. Use of strong
|
||||
authentication methods that do not reveal sensitive information is
|
||||
much preferred. If the URL represents a referral for an update
|
||||
operation, strong authentication methods SHOULD be used. Please
|
||||
refer to the Security Considerations section of [RFC4513] for more
|
||||
information.
|
||||
|
||||
The LDAP URL format allows the specification of an arbitrary LDAP
|
||||
search operation to be performed when evaluating the LDAP URL.
|
||||
Following an LDAP URL may cause unexpected results, for example, the
|
||||
retrieval of large amounts of data or the initiation of a long-lived
|
||||
|
||||
|
||||
|
||||
Smith & Howes Standards Track [Page 8]
|
||||
|
||||
RFC 4516 LDAP: Uniform Resource Locator June 2006
|
||||
|
||||
|
||||
search. The security implications of resolving an LDAP URL are the
|
||||
same as those of resolving an LDAP search query.
|
||||
|
||||
6. Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
|
||||
10646", STD 63, RFC 3629, November 2003.
|
||||
|
||||
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
|
||||
Resource Identifier (URI): Generic Syntax", STD 66, RFC
|
||||
3986, January 2005.
|
||||
|
||||
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
||||
Specifications: ABNF", RFC 4234, October 2005.
|
||||
|
||||
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
|
||||
(LDAP): Technical Specification Road Map", RFC 4510, June
|
||||
2006.
|
||||
|
||||
[RFC4511] Sermersheim, J., Ed., "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., Ed., "Lightweight Directory Access Protocol
|
||||
(LDAP): Authentication Methods and Security Mechanisms",
|
||||
RFC 4513, June 2006.
|
||||
|
||||
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
|
||||
(LDAP): String Representation of Distinguished Names", RFC
|
||||
4514, June 2006.
|
||||
|
||||
[RFC4515] Smith, M. Ed. and T. Howes, "Lightweight Directory Access
|
||||
Protocol (LDAP): String Representation of Search Filters",
|
||||
RFC 4515, June 2006.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Smith & Howes Standards Track [Page 9]
|
||||
|
||||
RFC 4516 LDAP: Uniform Resource Locator June 2006
|
||||
|
||||
|
||||
7. Informative References
|
||||
|
||||
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
|
||||
Resource Identifiers (URI): Generic Syntax", RFC 2396,
|
||||
August 1998.
|
||||
|
||||
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
|
||||
Considerations for the Lightweight Directory Access
|
||||
Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
|
||||
|
||||
8. Acknowledgements
|
||||
|
||||
The LDAP URL format was originally defined at the University of
|
||||
Michigan. This material is based upon work supported by the National
|
||||
Science Foundation under Grant No. NCR-9416667. The support of both
|
||||
the University of Michigan and the National Science Foundation is
|
||||
gratefully acknowledged.
|
||||
|
||||
This document obsoletes RFC 2255 by Tim Howes and Mark Smith.
|
||||
Changes included in this revised specification are based upon
|
||||
discussions among the authors, discussions within the LDAP (v3)
|
||||
Revision Working Group (ldapbis), and discussions within other IETF
|
||||
Working Groups. The contributions of individuals in these working
|
||||
groups is gratefully acknowledged. Several people in particular have
|
||||
made valuable comments on this document: RL "Bob" Morgan, Mark Wahl,
|
||||
Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special
|
||||
thanks for their contributions.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Smith & Howes Standards Track [Page 10]
|
||||
|
||||
RFC 4516 LDAP: Uniform Resource Locator June 2006
|
||||
|
||||
|
||||
Appendix A: Changes Since RFC 2255
|
||||
|
||||
A.1. Technical Changes
|
||||
|
||||
The following technical changes were made to the contents of the "URL
|
||||
Definition" section:
|
||||
|
||||
Revised all of the ABNF to use common productions from [RFC4512].
|
||||
|
||||
Replaced references to [RFC2396] with a reference to [RFC3986] (this
|
||||
allows literal IPv6 addresses to be used inside the <host> portion of
|
||||
the URL, and a note was added to remind the reader of this
|
||||
enhancement). Referencing [RFC3986] required changes to the ABNF and
|
||||
text so that productions that are no longer defined by [RFC3986] are
|
||||
not used. For example, <hostport> is not defined by [RFC3986] so it
|
||||
has been replaced with host [COLON port]. Note that [RFC3986]
|
||||
includes new definitions for the "Reserved" and "Unreserved" sets of
|
||||
characters, and the net result is that the following two additional
|
||||
characters should be percent-encoded when they appear anywhere in the
|
||||
data used to construct an LDAP URL: "[" and "]" (these two characters
|
||||
were first added to the Reserved set by RFC 2732).
|
||||
|
||||
Changed the definition of <attrdesc> to refer to <attributeSelector>
|
||||
from [RFC4511]. This allows the use of "*" in the <attrdesc> part of
|
||||
the URL. It is believed that existing implementations of RFC 2255
|
||||
already support this.
|
||||
|
||||
Avoided use of <prose-val> (bracketed-string) productions in the
|
||||
<dn>, <host>, <attrdesc>, and <exvalue> rules.
|
||||
|
||||
Changed the ABNF for <ldapurl> to group the <dn> component with the
|
||||
preceding <SLASH>.
|
||||
|
||||
Changed the <extype> rule to be an <oid> from [RFC4512].
|
||||
|
||||
Changed the text about extension types so it references [RFC4520].
|
||||
Reordered rules to more closely follow the order in which the
|
||||
elements appear in the URL.
|
||||
|
||||
"Bindname Extension": removed due to lack of known implementations.
|
||||
|
||||
A.2. Editorial Changes
|
||||
|
||||
Changed document title to include "LDAP:" prefix.
|
||||
|
||||
IESG Note: removed note about lack of satisfactory mandatory
|
||||
authentication mechanisms.
|
||||
|
||||
|
||||
|
||||
|
||||
Smith & Howes Standards Track [Page 11]
|
||||
|
||||
RFC 4516 LDAP: Uniform Resource Locator June 2006
|
||||
|
||||
|
||||
"Status of this Memo" section: updated boilerplate to match current
|
||||
I-D guidelines.
|
||||
|
||||
"Abstract" section: separated from introductory material.
|
||||
|
||||
"Table of Contents" and "Intellectual Property" sections: added.
|
||||
|
||||
"Introduction" section: new section; separated from the Abstract.
|
||||
Changed the text indicate that RFC 2255 is replaced by this document
|
||||
(instead of RFC 1959). Added text to indicate that LDAP URLs are
|
||||
used for references and referrals. Fixed typo (replaced the nonsense
|
||||
phrase "to perform to retrieve" with "used to retrieve"). Added a
|
||||
note to let the reader know that not all of the parameters of the
|
||||
LDAP search operation described in [RFC4511] can be expressed using
|
||||
this format.
|
||||
|
||||
"URL Definition" section: removed second copy of <ldapurl> grammar
|
||||
and following two paragraphs (editorial error in RFC 2255). Fixed
|
||||
line break within '!' sequence. Reformatted the ABNF to improve
|
||||
readability by aligning comments and adding some blank lines.
|
||||
Replaced "residing in the LDAP server" with "accessible from the LDAP
|
||||
server" in the sentence immediately following the ABNF. Removed the
|
||||
sentence "Individual attrdesc names are as defined for
|
||||
AttributeDescription in [RFC4511]." because [RFC4511]'s
|
||||
<attributeSelector> is now used directly in the ABNF. Reworded last
|
||||
paragraph to clarify which characters must be percent-encoded. Added
|
||||
text to indicate that LDAP URLs are used for references and
|
||||
referrals. Added text that refers to the ABNF from RFC 4234.
|
||||
Clarified and strengthened the requirements with respect to
|
||||
processing of URLs that contain implemented and not implemented
|
||||
extensions (the approach now closely matches that specified in
|
||||
[RFC4511] for LDAP controls).
|
||||
|
||||
"Defaults for Fields of the LDAP URL" section: added; formed by
|
||||
moving text about defaults out of the "URL Definition" section.
|
||||
Replaced direct reference to the attribute name "*" with a reference
|
||||
to the special <alluserattrs> selector "*" defined in [RFC4511].
|
||||
|
||||
"URL Processing" section: removed.
|
||||
|
||||
"Examples" section: Modified examples to use example.com and
|
||||
example.net hostnames. Added missing '?' to the LDAP URL example
|
||||
whose filter contains three null bytes. Removed space after one
|
||||
comma within a DN. Revised the bindname example to use e-bindname.
|
||||
Changed the name of an attribute used in one example from "int" to
|
||||
"four-octet" to avoid potential confusion. Added an example that
|
||||
demonstrates the interaction between DN escaping and URL percent-
|
||||
encoding. Added some examples to show URL equivalence with respect
|
||||
|
||||
|
||||
|
||||
Smith & Howes Standards Track [Page 12]
|
||||
|
||||
RFC 4516 LDAP: Uniform Resource Locator June 2006
|
||||
|
||||
|
||||
to the <dn> portion of the URL. Used uppercase in some examples to
|
||||
remind the reader that some tokens are case-insensitive.
|
||||
|
||||
"Security Considerations" section: Added a note about connection
|
||||
reuse. Added a note about using strong authentication methods for
|
||||
updates. Added a reference to [RFC4513]. Added note that simply
|
||||
opening a connection may violate some users' privacy requirements.
|
||||
Adopted the working group's revised LDAP terminology specification by
|
||||
replacing the word "connection" with "LDAP session" or "LDAP
|
||||
connection" as appropriate.
|
||||
|
||||
"Acknowledgements" section: added statement that this document
|
||||
obsoletes RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and
|
||||
Hallvard Furuseth.
|
||||
|
||||
"Normative References" section: renamed from "References" per new RFC
|
||||
guidelines. Changed from [1] style to [RFC4511] style throughout the
|
||||
document. Added references to RFC 4234 and RFC 3629. Updated all
|
||||
RFC 1738 references to point to the appropriate sections within
|
||||
[RFC3986]. Updated the LDAP references to refer to LDAPBis WG
|
||||
documents. Removed the reference to the LDAP Attribute Syntaxes
|
||||
document and added references to the [RFC4513], [RFC4520], and
|
||||
[RFC4510] documents.
|
||||
|
||||
"Informative References" section: added.
|
||||
|
||||
Header and "Authors' Addresses" sections: added "editor" next to Mark
|
||||
Smith's name. Updated affiliation and contact information.
|
||||
|
||||
Copyright: updated the year.
|
||||
|
||||
Throughout the document: surrounded the names of all ABNF productions
|
||||
with "<" and ">" where they are used in descriptive text.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Smith & Howes Standards Track [Page 13]
|
||||
|
||||
RFC 4516 LDAP: Uniform Resource Locator June 2006
|
||||
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Mark Smith, Editor
|
||||
Pearl Crescent, LLC
|
||||
447 Marlpool Dr.
|
||||
Saline, MI 48176
|
||||
USA
|
||||
|
||||
Phone: +1 734 944-2856
|
||||
EMail: mcs@pearlcrescent.com
|
||||
|
||||
|
||||
Tim Howes
|
||||
Opsware, Inc.
|
||||
599 N. Mathilda Ave.
|
||||
Sunnyvale, CA 94085
|
||||
USA
|
||||
|
||||
Phone: +1 408 744-7509
|
||||
EMail: howes@opsware.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Smith & Howes Standards Track [Page 14]
|
||||
|
||||
RFC 4516 LDAP: Uniform Resource Locator June 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights 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; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Smith & Howes Standards Track [Page 15]
|
||||
|
||||
2971
source/ldap_server/devdocs/rfc4517.txt
Normal file
2971
source/ldap_server/devdocs/rfc4517.txt
Normal file
File diff suppressed because it is too large
Load Diff
787
source/ldap_server/devdocs/rfc4518.txt
Normal file
787
source/ldap_server/devdocs/rfc4518.txt
Normal file
@ -0,0 +1,787 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group K. Zeilenga
|
||||
Request for Comments: 4518 OpenLDAP Foundation
|
||||
Category: Standards Track June 2006
|
||||
|
||||
|
||||
Lightweight Directory Access Protocol (LDAP):
|
||||
Internationalized String Preparation
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
The previous Lightweight Directory Access Protocol (LDAP) technical
|
||||
specifications did not precisely define how character string matching
|
||||
is to be performed. This led to a number of usability and
|
||||
interoperability problems. This document defines string preparation
|
||||
algorithms for character-based matching rules defined for use in
|
||||
LDAP.
|
||||
|
||||
1. Introduction
|
||||
|
||||
1.1. Background
|
||||
|
||||
A Lightweight Directory Access Protocol (LDAP) [RFC4510] matching
|
||||
rule [RFC4517] defines an algorithm for determining whether a
|
||||
presented value matches an attribute value in accordance with the
|
||||
criteria defined for the rule. The proposition may be evaluated to
|
||||
True, False, or Undefined.
|
||||
|
||||
True - the attribute contains a matching value,
|
||||
|
||||
False - the attribute contains no matching value,
|
||||
|
||||
Undefined - it cannot be determined whether the attribute contains
|
||||
a matching value.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 1]
|
||||
|
||||
RFC 4518 LDAP: Internationalized String Preparation June 2006
|
||||
|
||||
|
||||
For instance, the caseIgnoreMatch matching rule may be used to
|
||||
compare whether the commonName attribute contains a particular value
|
||||
without regard for case and insignificant spaces.
|
||||
|
||||
1.2. X.500 String Matching Rules
|
||||
|
||||
"X.520: Selected attribute types" [X.520] provides (among other
|
||||
things) value syntaxes and matching rules for comparing values
|
||||
commonly used in the directory [X.500]. These specifications are
|
||||
inadequate for strings composed of Unicode [Unicode] characters.
|
||||
|
||||
The caseIgnoreMatch matching rule [X.520], for example, is simply
|
||||
defined as being a case-insensitive comparison where insignificant
|
||||
spaces are ignored. For printableString, there is only one space
|
||||
character and case mapping is bijective, hence this definition is
|
||||
sufficient. However, for Unicode string types such as
|
||||
universalString, this is not sufficient. For example, a case-
|
||||
insensitive matching implementation that folded lowercase characters
|
||||
to uppercase would yield different results than an implementation
|
||||
that used uppercase to lowercase folding. Or one implementation may
|
||||
view space as referring to only SPACE (U+0020), a second
|
||||
implementation may view any character with the space separator (Zs)
|
||||
property as a space, and another implementation may view any
|
||||
character with the whitespace (WS) category as a space.
|
||||
|
||||
The lack of precise specification for character string matching has
|
||||
led to significant interoperability problems. When used in
|
||||
certificate chain validation, security vulnerabilities can arise. To
|
||||
address these problems, this document defines precise algorithms for
|
||||
preparing character strings for matching.
|
||||
|
||||
1.3. Relationship to "stringprep"
|
||||
|
||||
The character string preparation algorithms described in this
|
||||
document are based upon the "stringprep" approach [RFC3454]. In
|
||||
"stringprep", presented and stored values are first prepared for
|
||||
comparison so that a character-by-character comparison yields the
|
||||
"correct" result.
|
||||
|
||||
The approach used here is a refinement of the "stringprep" [RFC3454]
|
||||
approach. Each algorithm involves two additional preparation steps.
|
||||
|
||||
a) Prior to applying the Unicode string preparation steps outlined in
|
||||
"stringprep", the string is transcoded to Unicode.
|
||||
|
||||
b) After applying the Unicode string preparation steps outlined in
|
||||
"stringprep", the string is modified to appropriately handle
|
||||
characters insignificant to the matching rule.
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 2]
|
||||
|
||||
RFC 4518 LDAP: Internationalized String Preparation June 2006
|
||||
|
||||
|
||||
Hence, preparation of character strings for X.500 [X.500] matching
|
||||
[X.501] involves the following steps:
|
||||
|
||||
1) Transcode
|
||||
2) Map
|
||||
3) Normalize
|
||||
4) Prohibit
|
||||
5) Check Bidi (Bidirectional)
|
||||
6) Insignificant Character Handling
|
||||
|
||||
These steps are described in Section 2.
|
||||
|
||||
It is noted that while various tables of Unicode characters included
|
||||
or referenced by this specification are derived from Unicode
|
||||
[Unicode] data, these tables are to be considered definitive for the
|
||||
purpose of implementing this specification.
|
||||
|
||||
1.4. Relationship to the LDAP Technical Specification
|
||||
|
||||
This document is an integral part of the LDAP technical specification
|
||||
[RFC4510], which obsoletes the previously defined LDAP technical
|
||||
specification [RFC3377] in its entirety.
|
||||
|
||||
This document details new LDAP internationalized character string
|
||||
preparation algorithms used by [RFC4517] and possible other technical
|
||||
specifications defining LDAP syntaxes and/or matching rules.
|
||||
|
||||
1.5. Relationship to X.500
|
||||
|
||||
LDAP is defined [RFC4510] in X.500 terms as an X.500 access
|
||||
mechanism. As such, there is a strong desire for alignment between
|
||||
LDAP and X.500 syntax and semantics. The character string
|
||||
preparation algorithms described in this document are based upon
|
||||
"Internationalized String Matching Rules for X.500" [XMATCH] proposal
|
||||
to ITU/ISO Joint Study Group 2.
|
||||
|
||||
1.6. Conventions and Terms
|
||||
|
||||
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].
|
||||
|
||||
Character names in this document use the notation for code points and
|
||||
names from the Unicode Standard [Unicode]. For example, the letter
|
||||
"a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
|
||||
In the lists of mappings and the prohibited characters, the "U+" is
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 3]
|
||||
|
||||
RFC 4518 LDAP: Internationalized String Preparation June 2006
|
||||
|
||||
|
||||
left off to make the lists easier to read. The comments for
|
||||
character ranges are shown in square brackets (such as "[CONTROL
|
||||
CHARACTERS]") and do not come from the standard.
|
||||
|
||||
Note: a glossary of terms used in Unicode can be found in [Glossary].
|
||||
Information on the Unicode character encoding model can be found in
|
||||
[CharModel].
|
||||
|
||||
The term "combining mark", as used in this specification, refers to
|
||||
any Unicode [Unicode] code point that has a mark property (Mn, Mc,
|
||||
Me). Appendix A provides a definitive list of combining marks.
|
||||
|
||||
2. String Preparation
|
||||
|
||||
The following six-step process SHALL be applied to each presented and
|
||||
attribute value in preparation for character string matching rule
|
||||
evaluation.
|
||||
|
||||
1) Transcode
|
||||
2) Map
|
||||
3) Normalize
|
||||
4) Prohibit
|
||||
5) Check bidi
|
||||
6) Insignificant Character Handling
|
||||
|
||||
Failure in any step causes the assertion to evaluate to Undefined.
|
||||
|
||||
The character repertoire of this process is Unicode 3.2 [Unicode].
|
||||
|
||||
Note that this six-step process specification is intended to describe
|
||||
expected matching behavior. Implementations are free to use
|
||||
alternative processes so long as the matching rule evaluation
|
||||
behavior provided is consistent with the behavior described by this
|
||||
specification.
|
||||
|
||||
2.1. Transcode
|
||||
|
||||
Each non-Unicode string value is transcoded to Unicode.
|
||||
|
||||
PrintableString [X.680] values are transcoded directly to Unicode.
|
||||
|
||||
UniversalString, UTF8String, and bmpString [X.680] values need not be
|
||||
transcoded as they are Unicode-based strings (in the case of
|
||||
bmpString, a subset of Unicode).
|
||||
|
||||
TeletexString [X.680] values are transcoded to Unicode. As there is
|
||||
no standard for mapping TeletexString values to Unicode, the mapping
|
||||
is left a local matter.
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 4]
|
||||
|
||||
RFC 4518 LDAP: Internationalized String Preparation June 2006
|
||||
|
||||
|
||||
For these and other reasons, use of TeletexString is NOT RECOMMENDED.
|
||||
|
||||
The output is the transcoded string.
|
||||
|
||||
2.2. Map
|
||||
|
||||
SOFT HYPHEN (U+00AD) and MONGOLIAN TODO SOFT HYPHEN (U+1806) code
|
||||
points are mapped to nothing. COMBINING GRAPHEME JOINER (U+034F) and
|
||||
VARIATION SELECTORs (U+180B-180D, FF00-FE0F) code points are also
|
||||
mapped to nothing. The OBJECT REPLACEMENT CHARACTER (U+FFFC) is
|
||||
mapped to nothing.
|
||||
|
||||
CHARACTER TABULATION (U+0009), LINE FEED (LF) (U+000A), LINE
|
||||
TABULATION (U+000B), FORM FEED (FF) (U+000C), CARRIAGE RETURN (CR)
|
||||
(U+000D), and NEXT LINE (NEL) (U+0085) are mapped to SPACE (U+0020).
|
||||
|
||||
All other control code (e.g., Cc) points or code points with a
|
||||
control function (e.g., Cf) are mapped to nothing. The following is
|
||||
a complete list of these code points: U+0000-0008, 000E-001F, 007F-
|
||||
0084, 0086-009F, 06DD, 070F, 180E, 200C-200F, 202A-202E, 2060-2063,
|
||||
206A-206F, FEFF, FFF9-FFFB, 1D173-1D17A, E0001, E0020-E007F.
|
||||
|
||||
ZERO WIDTH SPACE (U+200B) is mapped to nothing. All other code
|
||||
points with Separator (space, line, or paragraph) property (e.g., Zs,
|
||||
Zl, or Zp) are mapped to SPACE (U+0020). The following is a complete
|
||||
list of these code points: U+0020, 00A0, 1680, 2000-200A, 2028-2029,
|
||||
202F, 205F, 3000.
|
||||
|
||||
For case ignore, numeric, and stored prefix string matching rules,
|
||||
characters are case folded per B.2 of [RFC3454].
|
||||
|
||||
The output is the mapped string.
|
||||
|
||||
2.3. Normalize
|
||||
|
||||
The input string is to be normalized to Unicode Form KC
|
||||
(compatibility composed) as described in [UAX15]. The output is the
|
||||
normalized string.
|
||||
|
||||
2.4. Prohibit
|
||||
|
||||
All Unassigned code points are prohibited. Unassigned code points
|
||||
are listed in Table A.1 of [RFC3454].
|
||||
|
||||
Characters that, per Section 5.8 of [RFC3454], change display
|
||||
properties or are deprecated are prohibited. These characters are
|
||||
listed in Table C.8 of [RFC3454].
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 5]
|
||||
|
||||
RFC 4518 LDAP: Internationalized String Preparation June 2006
|
||||
|
||||
|
||||
Private Use code points are prohibited. These characters are listed
|
||||
in Table C.3 of [RFC3454].
|
||||
|
||||
All non-character code points are prohibited. These code points are
|
||||
listed in Table C.4 of [RFC3454].
|
||||
|
||||
Surrogate codes are prohibited. These characters are listed in Table
|
||||
C.5 of [RFC3454].
|
||||
|
||||
The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited.
|
||||
|
||||
The step fails if the input string contains any prohibited code
|
||||
point. Otherwise, the output is the input string.
|
||||
|
||||
2.5. Check bidi
|
||||
|
||||
Bidirectional characters are ignored.
|
||||
|
||||
2.6. Insignificant Character Handling
|
||||
|
||||
In this step, the string is modified to ensure proper handling of
|
||||
characters insignificant to the matching rule. This modification
|
||||
differs from matching rule to matching rule.
|
||||
|
||||
Section 2.6.1 applies to case ignore and exact string matching.
|
||||
Section 2.6.2 applies to numericString matching.
|
||||
Section 2.6.3 applies to telephoneNumber matching.
|
||||
|
||||
2.6.1. Insignificant Space Handling
|
||||
|
||||
For the purposes of this section, a space is defined to be the SPACE
|
||||
(U+0020) code point followed by no combining marks.
|
||||
|
||||
NOTE - The previous steps ensure that the string cannot contain
|
||||
any code points in the separator class, other than SPACE
|
||||
(U+0020).
|
||||
|
||||
For input strings that are attribute values or non-substring
|
||||
assertion values: If the input string contains no non-space
|
||||
character, then the output is exactly two SPACEs. Otherwise (the
|
||||
input string contains at least one non-space character), the string
|
||||
is modified such that the string starts with exactly one space
|
||||
character, ends with exactly one SPACE character, and any inner
|
||||
(non-empty) sequence of space characters is replaced with exactly two
|
||||
SPACE characters. For instance, the input strings
|
||||
"foo<SPACE>bar<SPACE><SPACE>", result in the output
|
||||
"<SPACE>foo<SPACE><SPACE>bar<SPACE>".
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 6]
|
||||
|
||||
RFC 4518 LDAP: Internationalized String Preparation June 2006
|
||||
|
||||
|
||||
For input strings that are substring assertion values: If the string
|
||||
being prepared contains no non-space characters, then the output
|
||||
string is exactly one SPACE. Otherwise, the following steps are
|
||||
taken:
|
||||
|
||||
- If the input string is an initial substring, it is modified to
|
||||
start with exactly one SPACE character;
|
||||
|
||||
- If the input string is an initial or an any substring that ends in
|
||||
one or more space characters, it is modified to end with exactly
|
||||
one SPACE character;
|
||||
|
||||
- If the input string is an any or a final substring that starts in
|
||||
one or more space characters, it is modified to start with exactly
|
||||
one SPACE character; and
|
||||
|
||||
- If the input string is a final substring, it is modified to end
|
||||
with exactly one SPACE character.
|
||||
|
||||
For instance, for the input string "foo<SPACE>bar<SPACE><SPACE>" as
|
||||
an initial substring, the output would be
|
||||
"<SPACE>foo<SPACE><SPACE>bar<SPACE>". As an any or final substring,
|
||||
the same input would result in "foo<SPACE>bar<SPACE>".
|
||||
|
||||
Appendix B discusses the rationale for the behavior.
|
||||
|
||||
2.6.2. numericString Insignificant Character Handling
|
||||
|
||||
For the purposes of this section, a space is defined to be the SPACE
|
||||
(U+0020) code point followed by no combining marks.
|
||||
|
||||
All spaces are regarded as insignificant and are to be removed.
|
||||
|
||||
For example, removal of spaces from the Form KC string:
|
||||
"<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>"
|
||||
would result in the output string:
|
||||
"123456"
|
||||
and the Form KC string:
|
||||
"<SPACE><SPACE><SPACE>"
|
||||
would result in the output string:
|
||||
"" (an empty string).
|
||||
|
||||
2.6.3. telephoneNumber Insignificant Character Handling
|
||||
|
||||
For the purposes of this section, a hyphen is defined to be a
|
||||
HYPHEN-MINUS (U+002D), ARMENIAN HYPHEN (U+058A), HYPHEN (U+2010),
|
||||
NON-BREAKING HYPHEN (U+2011), MINUS SIGN (U+2212), SMALL HYPHEN-MINUS
|
||||
(U+FE63), or FULLWIDTH HYPHEN-MINUS (U+FF0D) code point followed by
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 7]
|
||||
|
||||
RFC 4518 LDAP: Internationalized String Preparation June 2006
|
||||
|
||||
|
||||
no combining marks and a space is defined to be the SPACE (U+0020)
|
||||
code point followed by no combining marks.
|
||||
|
||||
All hyphens and spaces are considered insignificant and are to be
|
||||
removed.
|
||||
|
||||
For example, removal of hyphens and spaces from the Form KC string:
|
||||
"<SPACE><HYPHEN>123<SPACE><SPACE>456<SPACE><HYPHEN>"
|
||||
would result in the output string:
|
||||
"123456"
|
||||
and the Form KC string:
|
||||
"<HYPHEN><HYPHEN><HYPHEN>"
|
||||
would result in the (empty) output string:
|
||||
"".
|
||||
|
||||
3. Security Considerations
|
||||
|
||||
"Preparation of Internationalized Strings ("stringprep")" [RFC3454]
|
||||
security considerations generally apply to the algorithms described
|
||||
here.
|
||||
|
||||
4. Acknowledgements
|
||||
|
||||
The approach used in this document is based upon design principles
|
||||
and algorithms described in "Preparation of Internationalized Strings
|
||||
('stringprep')" [RFC3454] by Paul Hoffman and Marc Blanchet. Some
|
||||
additional guidance was drawn from Unicode Technical Standards,
|
||||
Technical Reports, and Notes.
|
||||
|
||||
This document is a product of the IETF LDAP Revision (LDAPBIS)
|
||||
Working Group.
|
||||
|
||||
5. References
|
||||
|
||||
5.1. Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
|
||||
Internationalized Strings ("stringprep")", RFC 3454,
|
||||
December 2002.
|
||||
|
||||
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
|
||||
(LDAP): Technical Specification Road Map", RFC 4510,
|
||||
June 2006.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 8]
|
||||
|
||||
RFC 4518 LDAP: Internationalized String Preparation June 2006
|
||||
|
||||
|
||||
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
|
||||
(LDAP): Syntaxes and Matching Rules", RFC 4517, June
|
||||
2006.
|
||||
|
||||
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
|
||||
3.2.0" is defined by "The Unicode Standard, Version
|
||||
3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
|
||||
61633-5), as amended by the "Unicode Standard Annex
|
||||
#27: Unicode 3.1"
|
||||
(http://www.unicode.org/reports/tr27/) and by the
|
||||
"Unicode Standard Annex #28: Unicode 3.2"
|
||||
(http://www.unicode.org/reports/tr28/).
|
||||
|
||||
[UAX15] Davis, M. and M. Duerst, "Unicode Standard Annex #15:
|
||||
Unicode Normalization Forms, Version 3.2.0".
|
||||
<http://www.unicode.org/unicode/reports/tr15/tr15-
|
||||
22.html>, March 2002.
|
||||
|
||||
[X.680] International Telecommunication Union -
|
||||
Telecommunication Standardization Sector, "Abstract
|
||||
Syntax Notation One (ASN.1) - Specification of Basic
|
||||
Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
|
||||
|
||||
5.2. Informative References
|
||||
|
||||
[X.500] International Telecommunication Union -
|
||||
Telecommunication Standardization Sector, "The
|
||||
Directory -- Overview of concepts, models and
|
||||
services," X.500(1993) (also ISO/IEC 9594-1:1994).
|
||||
|
||||
[X.501] International Telecommunication Union -
|
||||
Telecommunication Standardization Sector, "The
|
||||
Directory -- Models," X.501(1993) (also ISO/IEC 9594-
|
||||
2:1994).
|
||||
|
||||
[X.520] International Telecommunication Union -
|
||||
Telecommunication Standardization Sector, "The
|
||||
Directory: Selected Attribute Types", X.520(1993) (also
|
||||
ISO/IEC 9594-6:1994).
|
||||
|
||||
[Glossary] The Unicode Consortium, "Unicode Glossary",
|
||||
<http://www.unicode.org/glossary/>.
|
||||
|
||||
[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
|
||||
#17, Character Encoding Model", UTR17,
|
||||
<http://www.unicode.org/unicode/reports/tr17/>, August
|
||||
2000.
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 9]
|
||||
|
||||
RFC 4518 LDAP: Internationalized String Preparation June 2006
|
||||
|
||||
|
||||
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
|
||||
Protocol (v3): Technical Specification", RFC 3377,
|
||||
September 2002.
|
||||
|
||||
[RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory
|
||||
Access Protocol (LDAP): String Representation of Search
|
||||
Filters", RFC 4515, June 2006.
|
||||
|
||||
[XMATCH] Zeilenga, K., "Internationalized String Matching Rules
|
||||
for X.500", Work in Progress.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 10]
|
||||
|
||||
RFC 4518 LDAP: Internationalized String Preparation June 2006
|
||||
|
||||
|
||||
Appendix A. Combining Marks
|
||||
|
||||
This appendix is normative.
|
||||
|
||||
This table was derived from Unicode [Unicode] data files; it lists
|
||||
all code points with the Mn, Mc, or Me properties. This table is to
|
||||
be considered definitive for the purposes of implementation of this
|
||||
specification.
|
||||
|
||||
0300-034F 0360-036F 0483-0486 0488-0489 0591-05A1
|
||||
05A3-05B9 05BB-05BC 05BF 05C1-05C2 05C4 064B-0655 0670
|
||||
06D6-06DC 06DE-06E4 06E7-06E8 06EA-06ED 0711 0730-074A
|
||||
07A6-07B0 0901-0903 093C 093E-094F 0951-0954 0962-0963
|
||||
0981-0983 09BC 09BE-09C4 09C7-09C8 09CB-09CD 09D7
|
||||
09E2-09E3 0A02 0A3C 0A3E-0A42 0A47-0A48 0A4B-0A4D
|
||||
0A70-0A71 0A81-0A83 0ABC 0ABE-0AC5 0AC7-0AC9 0ACB-0ACD
|
||||
0B01-0B03 0B3C 0B3E-0B43 0B47-0B48 0B4B-0B4D 0B56-0B57
|
||||
0B82 0BBE-0BC2 0BC6-0BC8 0BCA-0BCD 0BD7 0C01-0C03
|
||||
0C3E-0C44 0C46-0C48 0C4A-0C4D 0C55-0C56 0C82-0C83
|
||||
0CBE-0CC4 0CC6-0CC8 0CCA-0CCD 0CD5-0CD6 0D02-0D03
|
||||
0D3E-0D43 0D46-0D48 0D4A-0D4D 0D57 0D82-0D83 0DCA
|
||||
0DCF-0DD4 0DD6 0DD8-0DDF 0DF2-0DF3 0E31 0E34-0E3A
|
||||
0E47-0E4E 0EB1 0EB4-0EB9 0EBB-0EBC 0EC8-0ECD 0F18-0F19
|
||||
0F35 0F37 0F39 0F3E-0F3F 0F71-0F84 0F86-0F87 0F90-0F97
|
||||
0F99-0FBC 0FC6 102C-1032 1036-1039 1056-1059 1712-1714
|
||||
1732-1734 1752-1753 1772-1773 17B4-17D3 180B-180D 18A9
|
||||
20D0-20EA 302A-302F 3099-309A FB1E FE00-FE0F FE20-FE23
|
||||
1D165-1D169 1D16D-1D172 1D17B-1D182 1D185-1D18B
|
||||
1D1AA-1D1AD
|
||||
|
||||
Appendix B. Substrings Matching
|
||||
|
||||
This appendix is non-normative.
|
||||
|
||||
In the absence of substrings matching, the insignificant space
|
||||
handling for case ignore/exact matching could be simplified.
|
||||
Specifically, the handling could be to require that all sequences of
|
||||
one or more spaces be replaced with one space and, if the string
|
||||
contains non-space characters, removal of all leading spaces and
|
||||
trailing spaces.
|
||||
|
||||
In the presence of substrings matching, this simplified space
|
||||
handling would lead to unexpected and undesirable matching behavior.
|
||||
For instance:
|
||||
|
||||
1) (CN=foo\20*\20bar) would match the CN value "foobar";
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 11]
|
||||
|
||||
RFC 4518 LDAP: Internationalized String Preparation June 2006
|
||||
|
||||
|
||||
2) (CN=*\20foobar\20*) would match "foobar", but
|
||||
(CN=*\20*foobar*\20*) would not.
|
||||
|
||||
Note to readers not familiar with LDAP substrings matching: the LDAP
|
||||
filter [RFC4515] assertion (CN=A*B*C) says to "match any value (of
|
||||
the attribute CN) that begins with A, contains B after A, ends with C
|
||||
where C is also after B."
|
||||
|
||||
The first case illustrates that this simplified space handling would
|
||||
cause leading and trailing spaces in substrings of the string to be
|
||||
regarded as insignificant. However, only leading and trailing (as
|
||||
well as multiple consecutive spaces) of the string (as a whole) are
|
||||
insignificant.
|
||||
|
||||
The second case illustrates that this simplified space handling would
|
||||
cause sub-partitioning failures. That is, if a prepared any
|
||||
substring matches a partition of the attribute value, then an
|
||||
assertion constructed by subdividing that substring into multiple
|
||||
substrings should also match.
|
||||
|
||||
In designing an appropriate approach for space handling for
|
||||
substrings matching, one must study key aspects of X.500 case
|
||||
exact/ignore matching. X.520 [X.520] says:
|
||||
|
||||
The [substrings] rule returns TRUE if there is a partitioning of
|
||||
the attribute value (into portions) such that:
|
||||
|
||||
- the specified substrings (initial, any, final) match
|
||||
different portions of the value in the order of the strings
|
||||
sequence;
|
||||
|
||||
- initial, if present, matches the first portion of the value;
|
||||
|
||||
- final, if present, matches the last portion of the value;
|
||||
|
||||
- any, if present, matches some arbitrary portion of the
|
||||
value.
|
||||
|
||||
That is, the substrings assertion (CN=foo\20*\20bar) matches the
|
||||
attribute value "foo<SPACE><SPACE>bar" as the value can be
|
||||
partitioned into the portions "foo<SPACE>" and "<SPACE>bar" meeting
|
||||
the above requirements.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 12]
|
||||
|
||||
RFC 4518 LDAP: Internationalized String Preparation June 2006
|
||||
|
||||
|
||||
X.520 also says:
|
||||
|
||||
[T]he following spaces are regarded as not significant:
|
||||
|
||||
- leading spaces (i.e., those preceding the first character
|
||||
that is not a space);
|
||||
|
||||
- trailing spaces (i.e., those following the last character
|
||||
that is not a space);
|
||||
|
||||
- multiple consecutive spaces (these are taken as equivalent
|
||||
to a single space character).
|
||||
|
||||
This statement applies to the assertion values and attribute values
|
||||
as whole strings, and not individually to substrings of an assertion
|
||||
value. In particular, the statements should be taken to mean that if
|
||||
an assertion value and attribute value match without any
|
||||
consideration to insignificant characters, then that assertion value
|
||||
should also match any attribute value that differs only by inclusion
|
||||
nor removal of insignificant characters.
|
||||
|
||||
Hence the assertion (CN=foo\20*\20bar) matches
|
||||
"foo<SPACE><SPACE><SPACE>bar" and "foo<SPACE>bar" as these values
|
||||
only differ from "foo<SPACE><SPACE>bar" by the inclusion or removal
|
||||
of insignificant spaces.
|
||||
|
||||
Astute readers of this text will also note that there are special
|
||||
cases where the specified space handling does not ignore spaces that
|
||||
could be considered insignificant. For instance, the assertion
|
||||
(CN=\20*\20*\20) does not match "<SPACE><SPACE><SPACE>"
|
||||
(insignificant spaces present in value) or " " (insignificant spaces
|
||||
not present in value). However, as these cases have no practical
|
||||
application that cannot be met by simple assertions, e.g., (cn=\20),
|
||||
and this minor anomaly can only be fully addressed by a preparation
|
||||
algorithm to be used in conjunction with character-by-character
|
||||
partitioning and matching, the anomaly is considered acceptable.
|
||||
|
||||
Author's Address
|
||||
|
||||
Kurt D. Zeilenga
|
||||
OpenLDAP Foundation
|
||||
|
||||
EMail: Kurt@OpenLDAP.org
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 13]
|
||||
|
||||
RFC 4518 LDAP: Internationalized String Preparation June 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights 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; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 14]
|
||||
|
||||
1963
source/ldap_server/devdocs/rfc4519.txt
Normal file
1963
source/ldap_server/devdocs/rfc4519.txt
Normal file
File diff suppressed because it is too large
Load Diff
1067
source/ldap_server/devdocs/rfc4520.txt
Normal file
1067
source/ldap_server/devdocs/rfc4520.txt
Normal file
File diff suppressed because it is too large
Load Diff
899
source/ldap_server/devdocs/rfc4521.txt
Normal file
899
source/ldap_server/devdocs/rfc4521.txt
Normal file
@ -0,0 +1,899 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group K. Zeilenga
|
||||
Request for Comments: 4521 OpenLDAP Foundation
|
||||
BCP: 118 June 2006
|
||||
Category: Best Current Practice
|
||||
|
||||
|
||||
Considerations for
|
||||
Lightweight Directory Access Protocol (LDAP) Extensions
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet Best Current Practices for the
|
||||
Internet Community, and requests discussion and suggestions for
|
||||
improvements. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
The Lightweight Directory Access Protocol (LDAP) is extensible. It
|
||||
provides mechanisms for adding new operations, extending existing
|
||||
operations, and expanding user and system schemas. This document
|
||||
discusses considerations for designers of LDAP extensions.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Best Current Practice [Page 1]
|
||||
|
||||
RFC 4521 LDAP Extensions June 2006
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................3
|
||||
1.1. Terminology ................................................3
|
||||
2. General Considerations ..........................................4
|
||||
2.1. Scope of Extension .........................................4
|
||||
2.2. Interaction between extensions .............................4
|
||||
2.3. Discovery Mechanism ........................................4
|
||||
2.4. Internationalization Considerations ........................5
|
||||
2.5. Use of the Basic Encoding Rules ............................5
|
||||
2.6. Use of Formal Languages ....................................5
|
||||
2.7. Examples ...................................................5
|
||||
2.8. Registration of Protocol Values ............................5
|
||||
3. LDAP Operation Extensions .......................................6
|
||||
3.1. Controls ...................................................6
|
||||
3.1.1. Extending Bind Operation with Controls ..............6
|
||||
3.1.2. Extending the Start TLS Operation with Controls .....7
|
||||
3.1.3. Extending the Search Operation with Controls ........7
|
||||
3.1.4. Extending the Update Operations with Controls .......8
|
||||
3.1.5. Extending the Responseless Operations with Controls..8
|
||||
3.2. Extended Operations ........................................8
|
||||
3.3. Intermediate Responses .....................................8
|
||||
3.4. Unsolicited Notifications ..................................9
|
||||
4. Extending the LDAP ASN.1 Definition .............................9
|
||||
4.1. Result Codes ...............................................9
|
||||
4.2. LDAP Message Types .........................................9
|
||||
4.3. Authentication Methods ....................................10
|
||||
4.4. General ASN.1 Extensibility ...............................10
|
||||
5. Schema Extensions ..............................................10
|
||||
5.1. LDAP Syntaxes .............................................11
|
||||
5.2. Matching Rules ............................................11
|
||||
5.3. Attribute Types ...........................................12
|
||||
5.4. Object Classes ............................................12
|
||||
6. Other Extension Mechanisms .....................................12
|
||||
6.1. Attribute Description Options .............................12
|
||||
6.2. Authorization Identities ..................................12
|
||||
6.3. LDAP URL Extensions .......................................12
|
||||
7. Security Considerations ........................................12
|
||||
8. Acknowledgements ...............................................13
|
||||
9. References .....................................................13
|
||||
9.1. Normative References ......................................13
|
||||
9.2. Informative References ....................................15
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Best Current Practice [Page 2]
|
||||
|
||||
RFC 4521 LDAP Extensions June 2006
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
The Lightweight Directory Access Protocol (LDAP) [RFC4510] is an
|
||||
extensible protocol.
|
||||
|
||||
LDAP allows for new operations to be added and for existing
|
||||
operations to be enhanced [RFC4511].
|
||||
|
||||
LDAP allows additional schema to be defined [RFC4512][RFC4517]. This
|
||||
can include additional object classes, attribute types, matching
|
||||
rules, additional syntaxes, and other elements of schema. LDAP
|
||||
provides an ability to extend attribute types with options [RFC4512].
|
||||
|
||||
LDAP supports a Simple Authentication and Security Layer (SASL)
|
||||
authentication method [RFC4511][RFC4513]. SASL [RFC4422] is
|
||||
extensible. LDAP may be extended to support additional
|
||||
authentication methods [RFC4511].
|
||||
|
||||
LDAP supports establishment of Transport Layer Security (TLS)
|
||||
[RFC4511][RFC4513]. TLS [RFC4346] is extensible.
|
||||
|
||||
LDAP has an extensible Uniform Resource Locator (URL) format
|
||||
[RFC4516].
|
||||
|
||||
Lastly, LDAP allows for certain extensions to the protocol's Abstract
|
||||
Syntax Notation - One (ASN.1) [X.680] definition to be made. This
|
||||
facilitates a wide range of protocol enhancements, for example, new
|
||||
result codes needed to support extensions to be added through
|
||||
extension of the protocol's ASN.1 definition.
|
||||
|
||||
This document describes practices that engineers should consider when
|
||||
designing extensions to LDAP.
|
||||
|
||||
1.1. Terminology
|
||||
|
||||
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]. In
|
||||
this document, "the specification", as used by BCP 14, RFC 2119,
|
||||
refers to the engineering of LDAP extensions.
|
||||
|
||||
The term "Request Control" refers to a control attached to a client-
|
||||
generated message sent to a server. The term "Response Control"
|
||||
refers to a control attached to a server-generated message sent to a
|
||||
client.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Best Current Practice [Page 3]
|
||||
|
||||
RFC 4521 LDAP Extensions June 2006
|
||||
|
||||
|
||||
DIT stands for Directory Information Tree.
|
||||
DSA stands for Directory System Agent, a server.
|
||||
DSE stands for DSA-Specific Entry.
|
||||
DUA stands for Directory User Agent, a client.
|
||||
DN stands for Distinguished Name.
|
||||
|
||||
2. General Considerations
|
||||
|
||||
2.1. Scope of Extension
|
||||
|
||||
Mutually agreeing peers may, within the confines of an extension,
|
||||
agree to significant changes in protocol semantics. However,
|
||||
designers MUST consider the impact of an extension upon protocol
|
||||
peers that have not agreed to implement or otherwise recognize and
|
||||
support the extension. Extensions MUST be "truly optional"
|
||||
[RFC2119].
|
||||
|
||||
2.2. Interaction between extensions
|
||||
|
||||
Designers SHOULD consider how extensions they engineer interact with
|
||||
other extensions.
|
||||
|
||||
Designers SHOULD consider the extensibility of extensions they
|
||||
specify. Extensions to LDAP SHOULD themselves be extensible.
|
||||
|
||||
Except where it is stated otherwise, extensibility is implied.
|
||||
|
||||
2.3. Discovery Mechanism
|
||||
|
||||
Extensions SHOULD provide adequate discovery mechanisms.
|
||||
|
||||
As LDAP design is based upon the client-request/server-response
|
||||
paradigm, the general discovery approach is for the client to
|
||||
discover the capabilities of the server before utilizing a particular
|
||||
extension. Commonly, this discovery involves querying the root DSE
|
||||
and/or other DSEs for operational information associated with the
|
||||
extension. LDAP provides no mechanism for a server to discover the
|
||||
capabilities of a client.
|
||||
|
||||
The 'supportedControl' attribute [RFC4512] is used to advertise
|
||||
supported controls. The 'supportedExtension' attribute [RFC4512] is
|
||||
used to advertise supported extended operations. The
|
||||
'supportedFeatures' attribute [RFC4512] is used to advertise
|
||||
features. Other root DSE attributes MAY be defined to advertise
|
||||
other capabilities.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Best Current Practice [Page 4]
|
||||
|
||||
RFC 4521 LDAP Extensions June 2006
|
||||
|
||||
|
||||
2.4. Internationalization Considerations
|
||||
|
||||
LDAP is designed to support the full Unicode [Unicode] repertory of
|
||||
characters. Extensions SHOULD avoid unnecessarily restricting
|
||||
applications to subsets of Unicode (e.g., Basic Multilingual Plane,
|
||||
ISO 8859-1, ASCII, Printable String).
|
||||
|
||||
LDAP Language Tag options [RFC3866] provide a mechanism for tagging
|
||||
text (and other) values with language information. Extensions that
|
||||
define attribute types SHOULD allow use of language tags with these
|
||||
attributes.
|
||||
|
||||
2.5. Use of the Basic Encoding Rules
|
||||
|
||||
Numerous elements of LDAP are described using ASN.1 [X.680] and are
|
||||
encoded using a particular subset [Protocol, Section 5.2] of the
|
||||
Basic Encoding Rules (BER) [X.690]. To allow reuse of
|
||||
parsers/generators used in implementing the LDAP "core" technical
|
||||
specification [RFC4510], it is RECOMMENDED that extension elements
|
||||
(e.g., extension specific contents of controlValue, requestValue,
|
||||
responseValue fields) described by ASN.1 and encoded using BER be
|
||||
subjected to the restrictions of [Protocol, Section 5.2].
|
||||
|
||||
2.6. Use of Formal Languages
|
||||
|
||||
Formal languages SHOULD be used in specifications in accordance with
|
||||
IESG guidelines [FORMAL].
|
||||
|
||||
2.7. Examples
|
||||
|
||||
Example DN strings SHOULD conform to the syntax defined in [RFC4518].
|
||||
Example LDAP filter strings SHOULD conform to the syntax defined in
|
||||
[RFC4515]. Example LDAP URLs SHOULD conform to the syntax defined in
|
||||
[RFC4516]. Entries SHOULD be represented using LDIF [RFC2849].
|
||||
|
||||
2.8. Registration of Protocol Values
|
||||
|
||||
Designers SHALL register protocol values of their LDAP extensions in
|
||||
accordance with BCP 64, RFC 4520 [RFC4520]. Specifications that
|
||||
create new extensible protocol elements SHALL extend existing
|
||||
registries or establish new registries for values of these elements
|
||||
in accordance with BCP 64, RFC 4520 [RFC4520] and BCP 26, RFC 2434
|
||||
[RFC2434].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Best Current Practice [Page 5]
|
||||
|
||||
RFC 4521 LDAP Extensions June 2006
|
||||
|
||||
|
||||
3. LDAP Operation Extensions
|
||||
|
||||
Extensions SHOULD use controls in defining extensions that complement
|
||||
existing operations. Where the extension to be defined does not
|
||||
complement an existing operation, designers SHOULD consider defining
|
||||
an extended operation instead.
|
||||
|
||||
For example, a subtree delete operation could be designed as either
|
||||
an extension of the delete operation or as a new operation. As the
|
||||
feature complements the existing delete operation, use of the control
|
||||
mechanism to extend the delete operation is likely more appropriate.
|
||||
|
||||
As a counter (and contrived) example, a locate services operation (an
|
||||
operation that would return for a DN a set of LDAP URLs to services
|
||||
that may hold the entry named by this DN) could be designed as either
|
||||
a search operation or a new operation. As the feature doesn't
|
||||
complement the search operation (e.g., the operation is not contrived
|
||||
to search for entries held in the Directory Information Tree), it is
|
||||
likely more appropriate to define a new operation using the extended
|
||||
operation mechanism.
|
||||
|
||||
3.1. Controls
|
||||
|
||||
Controls [Protocol, Section 4.1.11] are the RECOMMENDED mechanism for
|
||||
extending existing operations. The existing operation can be a base
|
||||
operation defined in [RFC4511] (e.g., search, modify) , an extended
|
||||
operation (e.g., Start TLS [RFC4511], Password Modify [RFC3062]), or
|
||||
an operation defined as an extension to a base or extended operation.
|
||||
|
||||
Extensions SHOULD NOT return Response controls unless the server has
|
||||
specific knowledge that the client can make use of the control.
|
||||
Generally, the client requests the return of a particular response
|
||||
control by providing a related request control.
|
||||
|
||||
An existing operation MAY be extended to return IntermediateResponse
|
||||
messages [Protocol, Section 4.13].
|
||||
|
||||
Specifications of controls SHALL NOT attach additional semantics to
|
||||
the criticality of controls beyond those defined in [Protocol,
|
||||
Section 4.1.11]. A specification MAY mandate the criticality take on
|
||||
a particular value (e.g., TRUE or FALSE), where appropriate.
|
||||
|
||||
3.1.1. Extending Bind Operation with Controls
|
||||
|
||||
Controls attached to the request and response messages of a Bind
|
||||
Operation [RFC4511] are not protected by any security layers
|
||||
established by that Bind operation.
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Best Current Practice [Page 6]
|
||||
|
||||
RFC 4521 LDAP Extensions June 2006
|
||||
|
||||
|
||||
Specifications detailing controls extending the Bind operation SHALL
|
||||
detail that the Bind negotiated security layers do not protect the
|
||||
information contained in these controls and SHALL detail how the
|
||||
information in these controls is protected or why the information
|
||||
does not need protection.
|
||||
|
||||
It is RECOMMENDED that designers consider alternative mechanisms for
|
||||
providing the function. For example, an extended operation issued
|
||||
subsequent to the Bind operation (hence, protected by the security
|
||||
layers negotiated by the Bind operation) might be used to provide the
|
||||
desired function.
|
||||
|
||||
Additionally, designers of Bind control extensions MUST also consider
|
||||
how the controls' semantics interact with individual steps of a
|
||||
multi-step Bind operation. Note that some steps are optional and
|
||||
thus may require special attention in the design.
|
||||
|
||||
3.1.2. Extending the Start TLS Operation with Controls
|
||||
|
||||
Controls attached to the request and response messages of a Start TLS
|
||||
Operation [RFC4511] are not protected by the security layers
|
||||
established by the Start TLS operation.
|
||||
|
||||
Specifications detailing controls extending the Start TLS operation
|
||||
SHALL detail that the Start TLS negotiated security layers do not
|
||||
protect the information contained in these controls and SHALL detail
|
||||
how the information in these controls is protected or why the
|
||||
information does not need protection.
|
||||
|
||||
It is RECOMMENDED that designers consider alternative mechanisms for
|
||||
providing the function. For example, an extended operation issued
|
||||
subsequent to the Start TLS operation (hence, protected by the
|
||||
security layers negotiated by the Start TLS operation) might be used
|
||||
to provided the desired function.
|
||||
|
||||
3.1.3. Extending the Search Operation with Controls
|
||||
|
||||
The Search operation processing has two distinct phases:
|
||||
|
||||
- finding the base object; and
|
||||
|
||||
- searching for objects at or under that base object.
|
||||
|
||||
Specifications of controls extending the Search Operation should
|
||||
clearly state in which phase(s) the control's semantics apply.
|
||||
Semantics of controls that are not specific to the Search Operation
|
||||
SHOULD apply in the finding phase.
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Best Current Practice [Page 7]
|
||||
|
||||
RFC 4521 LDAP Extensions June 2006
|
||||
|
||||
|
||||
3.1.4. Extending the Update Operations with Controls
|
||||
|
||||
Update operations have properties of atomicity, consistency,
|
||||
isolation, and durability ([ACID]).
|
||||
|
||||
- atomicity: All or none of the DIT changes requested are made.
|
||||
|
||||
- consistency: The resulting DIT state must be conform to schema
|
||||
and other constraints.
|
||||
|
||||
- isolation: Intermediate states are not exposed.
|
||||
|
||||
- durability: The resulting DIT state is preserved until
|
||||
subsequently updated.
|
||||
|
||||
When defining a control that requests additional (or other) DIT
|
||||
changes be made to the DIT, these additional changes SHOULD NOT be
|
||||
treated as part of a separate transaction. The specification MUST be
|
||||
clear as to whether the additional DIT changes are part of the same
|
||||
or a separate transaction as the DIT changes expressed in the request
|
||||
of the base operation.
|
||||
|
||||
When defining a control that requests additional (or other) DIT
|
||||
changes be made to the DIT, the specification MUST be clear as to the
|
||||
order in which these and the base changes are to be applied to the
|
||||
DIT.
|
||||
|
||||
3.1.5. Extending the Responseless Operations with Controls
|
||||
|
||||
The Abandon and Unbind operations do not include a response message.
|
||||
For this reason, specifications for controls designed to be attached
|
||||
to Abandon and Unbind requests SHOULD mandate that the control's
|
||||
criticality be FALSE.
|
||||
|
||||
3.2. Extended Operations
|
||||
|
||||
Extended Operations [Protocol, Section 4.12] are the RECOMMENDED
|
||||
mechanism for defining new operations. An extended operation
|
||||
consists of an ExtendedRequest message, zero or more
|
||||
IntermediateResponse messages, and an ExtendedResponse message.
|
||||
|
||||
3.3. Intermediate Responses
|
||||
|
||||
Extensions SHALL use IntermediateResponse messages instead of
|
||||
ExtendedResponse messages to return intermediate results.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Best Current Practice [Page 8]
|
||||
|
||||
RFC 4521 LDAP Extensions June 2006
|
||||
|
||||
|
||||
3.4. Unsolicited Notifications
|
||||
|
||||
Unsolicited notifications [Protocol, Section 4.4] offer a capability
|
||||
for the server to notify the client of events not associated with the
|
||||
operation currently being processed.
|
||||
|
||||
Extensions SHOULD be designed such that unsolicited notifications are
|
||||
not returned unless the server has specific knowledge that the client
|
||||
can make use of the notification. Generally, the client requests the
|
||||
return of a particular unsolicited notification by performing a
|
||||
related extended operation.
|
||||
|
||||
For example, a time hack extension could be designed to return
|
||||
unsolicited notifications at regular intervals that were enabled by
|
||||
an extended operation (which possibly specified the desired
|
||||
interval).
|
||||
|
||||
4. Extending the LDAP ASN.1 Definition
|
||||
|
||||
LDAP allows limited extension [Protocol, Section 4] of the LDAP ASN.1
|
||||
definition [Protocol, Appendix B] to be made.
|
||||
|
||||
4.1. Result Codes
|
||||
|
||||
Extensions that specify new operations or enhance existing operations
|
||||
often need to define new result codes. The extension SHOULD be
|
||||
designed such that a client has a reasonably clear indication of the
|
||||
nature of the successful or non-successful result.
|
||||
|
||||
Extensions SHOULD use existing result codes to indicate conditions
|
||||
that are consistent with the intended meaning [RFC4511][X.511] of
|
||||
these codes. Extensions MAY introduce new result codes [RFC4520]
|
||||
where no existing result code provides an adequate indication of the
|
||||
nature of the result.
|
||||
|
||||
Extensions SHALL NOT disallow or otherwise restrict the return of
|
||||
general service result codes, especially those reporting a protocol,
|
||||
service, or security problem, or indicating that the server is unable
|
||||
or unwilling to complete the operation.
|
||||
|
||||
4.2. LDAP Message Types
|
||||
|
||||
While extensions can specify new types of LDAP messages by extending
|
||||
the protocolOp CHOICE of the LDAPMessage SEQUENCE, this is generally
|
||||
unnecessary and inappropriate. Existing operation extension
|
||||
mechanisms (e.g., extended operations, unsolicited notifications, and
|
||||
intermediate responses) SHOULD be used instead. However, there may
|
||||
be cases where an extension does not fit well into these mechanisms.
|
||||
|
||||
|
||||
|
||||
Zeilenga Best Current Practice [Page 9]
|
||||
|
||||
RFC 4521 LDAP Extensions June 2006
|
||||
|
||||
|
||||
In such cases, a new extension mechanism SHOULD be defined that can
|
||||
be used by multiple extensions that have similar needs.
|
||||
|
||||
4.3. Authentication Methods
|
||||
|
||||
The Bind operation currently supports two authentication methods,
|
||||
simple and SASL. SASL [RFC4422] is an extensible authentication
|
||||
framework used by multiple application-level protocols (e.g., BEEP,
|
||||
IMAP, SMTP). It is RECOMMENDED that new authentication processes be
|
||||
defined as SASL mechanisms. New LDAP authentication methods MAY be
|
||||
added to support new authentication frameworks.
|
||||
|
||||
The Bind operation's primary function is to establish the LDAP
|
||||
association [RFC4513]. No other operation SHALL be defined (or
|
||||
extended) to establish the LDAP association. However, other
|
||||
operations MAY be defined to establish other security associations
|
||||
(e.g., IPsec).
|
||||
|
||||
4.4. General ASN.1 Extensibility
|
||||
|
||||
Section 4 of [RFC4511] states the following:
|
||||
|
||||
In order to support future extensions to this protocol,
|
||||
extensibility is implied where it is allowed per ASN.1 (i.e.,
|
||||
sequence, set, choice, and enumerated types are extensible). In
|
||||
addition, ellipses (...) have been supplied in ASN.1 types that
|
||||
are explicitly extensible as discussed in [RFC4520]. Because of
|
||||
the implied extensibility, clients and servers MUST (unless
|
||||
otherwise specified) ignore trailing SEQUENCE components whose
|
||||
tags they do not recognize.
|
||||
|
||||
Designers SHOULD avoid introducing extensions that rely on
|
||||
unsuspecting implementations to ignore trailing components of
|
||||
SEQUENCE whose tags they do not recognize.
|
||||
|
||||
5. Schema Extensions
|
||||
|
||||
Extensions defining LDAP schema elements SHALL provide schema
|
||||
definitions conforming with syntaxes defined in [Models, Section
|
||||
4.1]. While provided definitions MAY be reformatted (line wrapped)
|
||||
for readability, this SHALL be noted in the specification.
|
||||
|
||||
For definitions that allow a NAME field, new schema elements SHOULD
|
||||
provide one and only one name. The name SHOULD be short.
|
||||
|
||||
Each schema definition allows a DESC field. The DESC field, if
|
||||
provided, SHOULD contain a short descriptive phrase. The DESC field
|
||||
MUST be regarded as informational. That is, the specification MUST
|
||||
|
||||
|
||||
|
||||
Zeilenga Best Current Practice [Page 10]
|
||||
|
||||
RFC 4521 LDAP Extensions June 2006
|
||||
|
||||
|
||||
be written such that its interpretation is the same with and without
|
||||
the provided DESC fields.
|
||||
|
||||
The extension SHALL NOT mandate that implementations provide the same
|
||||
DESC field in the schema they publish. Implementors MAY replace or
|
||||
remove the DESC field.
|
||||
|
||||
Published schema elements SHALL NOT be redefined. Replacement schema
|
||||
elements (new OIDs, new NAMEs) SHOULD be defined as needed.
|
||||
|
||||
Schema designers SHOULD reuse existing schema elements, where
|
||||
appropriate. However, any reuse MUST not alter the semantics of the
|
||||
element.
|
||||
|
||||
5.1. LDAP Syntaxes
|
||||
|
||||
Each LDAP syntax [RFC4517] is defined in terms of ASN.1 [X.680].
|
||||
Each extension detailing an LDAP syntax MUST specify the ASN.1 data
|
||||
definition associated with the syntax. A distinct LDAP syntax SHOULD
|
||||
be created for each distinct ASN.1 data definition (including
|
||||
constraints).
|
||||
|
||||
Each LDAP syntax SHOULD have a string encoding defined for it. It is
|
||||
RECOMMENDED that this string encoding be restricted to UTF-8
|
||||
[RFC3629] encoded Unicode [Unicode] characters. Use of Generic
|
||||
String Encoding Rules (GSER) [RFC3641][RFC3642] or other generic
|
||||
string encoding rules to provide string encodings for complex ASN.1
|
||||
data definitions is RECOMMENDED. Otherwise, it is RECOMMENDED that
|
||||
the string encoding be described using a formal language (e.g., ABNF
|
||||
[RFC4234]). Formal languages SHOULD be used in specifications in
|
||||
accordance with IESG guidelines [FORMAL].
|
||||
|
||||
If no string encoding is defined, the extension SHALL specify how the
|
||||
transfer encoding is to be indicated. Generally, the extension
|
||||
SHOULD mandate use of binary or other transfer encoding option.
|
||||
|
||||
5.2. Matching Rules
|
||||
|
||||
Three basic kinds of matching rules (e.g., EQUALITY, ORDERING, and
|
||||
SUBSTRING) may be associated with an attribute type. In addition,
|
||||
LDAP provides an extensible matching rule mechanism.
|
||||
|
||||
The matching rule specification SHOULD detail which kind of matching
|
||||
rule it is and SHOULD describe which kinds of values it can be used
|
||||
with.
|
||||
|
||||
In addition to requirements stated in the LDAP technical
|
||||
specification, equality matching rules SHOULD be commutative.
|
||||
|
||||
|
||||
|
||||
Zeilenga Best Current Practice [Page 11]
|
||||
|
||||
RFC 4521 LDAP Extensions June 2006
|
||||
|
||||
|
||||
5.3. Attribute Types
|
||||
|
||||
Designers SHOULD carefully consider how the structure of values is to
|
||||
be restricted. Designers SHOULD consider that servers will only
|
||||
enforce constraints of the attribute's syntax. That is, an attribute
|
||||
intended to hold URIs, but that has directoryString syntax, is not
|
||||
restricted to values that are URIs.
|
||||
|
||||
Designers SHOULD carefully consider which matching rules, if any, are
|
||||
appropriate for the attribute type. Matching rules specified for an
|
||||
attribute type MUST be compatible with the attribute type's syntax.
|
||||
|
||||
Extensions specifying operational attributes MUST detail how servers
|
||||
are to maintain and/or utilize values of each operational attribute.
|
||||
|
||||
5.4. Object Classes
|
||||
|
||||
Designers SHOULD carefully consider whether each attribute of an
|
||||
object class is required ("MUST") or allowed ("MAY").
|
||||
|
||||
Extensions specifying object classes that allow (or require)
|
||||
operational attributes MUST specify how servers are to maintain
|
||||
and/or utilize entries belonging to these object classes.
|
||||
|
||||
6. Other Extension Mechanisms
|
||||
|
||||
6.1. Attribute Description Options
|
||||
|
||||
Each option is identified by a string of letters, numbers, and
|
||||
hyphens. This string SHOULD be short.
|
||||
|
||||
6.2. Authorization Identities
|
||||
|
||||
Extensions interacting with authorization identities SHALL support
|
||||
the LDAP authzId format [RFC4513]. The authzId format is extensible.
|
||||
|
||||
6.3. LDAP URL Extensions
|
||||
|
||||
LDAP URL extensions are identified by a short string, a descriptor.
|
||||
Like other descriptors, the string SHOULD be short.
|
||||
|
||||
7. Security Considerations
|
||||
|
||||
LDAP does not place undue restrictions on the kinds of extensions
|
||||
that can be implemented. While this document attempts to outline
|
||||
some specific issues that designers need to consider, it is not (and
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Best Current Practice [Page 12]
|
||||
|
||||
RFC 4521 LDAP Extensions June 2006
|
||||
|
||||
|
||||
cannot be) all encompassing. Designers MUST do their own evaluations
|
||||
of the security considerations applicable to their extensions.
|
||||
|
||||
Designers MUST NOT assume that the LDAP "core" technical
|
||||
specification [RFC4510] adequately addresses the specific concerns
|
||||
surrounding their extensions or assume that their extensions have no
|
||||
specific concerns.
|
||||
|
||||
Extension specifications, however, SHOULD note whether security
|
||||
considerations specific to the feature they are extending, as well as
|
||||
general LDAP security considerations, apply to the extension.
|
||||
|
||||
8. Acknowledgements
|
||||
|
||||
The author thanks the IETF LDAP community for their thoughtful
|
||||
comments.
|
||||
|
||||
This work builds upon "LDAP Extension Style Guide" [GUIDE] by Bruce
|
||||
Greenblatt.
|
||||
|
||||
9. References
|
||||
|
||||
9.1. Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
|
||||
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
|
||||
October 1998.
|
||||
|
||||
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
|
||||
Technical Specification", RFC 2849, June 2000.
|
||||
|
||||
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
|
||||
10646", STD 63, RFC 3629, November 2003.
|
||||
|
||||
[RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
|
||||
Types", RFC 3641, October 2003.
|
||||
|
||||
[RFC3642] Legg, S., "Common Elements of Generic String Encoding
|
||||
Rules (GSER) Encodings", RFC 3642, October 2003.
|
||||
|
||||
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
|
||||
(LDAP): Directory Information Models", RFC 4512, June
|
||||
2006.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Best Current Practice [Page 13]
|
||||
|
||||
RFC 4521 LDAP Extensions June 2006
|
||||
|
||||
|
||||
[RFC3866] Zeilenga, K., Ed., "Language Tags and Ranges in the
|
||||
Lightweight Directory Access Protocol (LDAP)", RFC 3866,
|
||||
July 2004.
|
||||
|
||||
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
||||
Specifications: ABNF", RFC 4234, October 2005.
|
||||
|
||||
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
|
||||
(LDAP): Technical Specification Road Map", RFC 4510, June
|
||||
2006.
|
||||
|
||||
[RFC4511] Sermersheim, J., Ed., "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., Ed., "Lightweight Directory Access Protocol
|
||||
(LDAP): Authentication Methods and Security Mechanisms",
|
||||
RFC 4513, June 2006.
|
||||
|
||||
[RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory Access
|
||||
Protocol (LDAP): String Representation of Search Filters",
|
||||
RFC 4515, June 2006.
|
||||
|
||||
[RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access
|
||||
Protocol (LDAP): Uniform Resource Locator", RFC 4516, June
|
||||
2006.
|
||||
|
||||
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
|
||||
(LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
|
||||
|
||||
[RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol
|
||||
(LDAP): String Representation of Distinguished Names", RFC
|
||||
4518, June 2006.
|
||||
|
||||
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
|
||||
Considerations for the Lightweight Directory Access
|
||||
Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
|
||||
|
||||
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
|
||||
Authentication and Security Layer (SASL)", RFC 4422, June
|
||||
2006.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Best Current Practice [Page 14]
|
||||
|
||||
RFC 4521 LDAP Extensions June 2006
|
||||
|
||||
|
||||
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
|
||||
3.2.0" is defined by "The Unicode Standard, Version 3.0"
|
||||
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
|
||||
as amended by the "Unicode Standard Annex #27: Unicode
|
||||
3.1" (http://www.unicode.org/reports/tr27/) and by the
|
||||
"Unicode Standard Annex #28: Unicode 3.2"
|
||||
(http://www.unicode.org/reports/tr28/).
|
||||
|
||||
[FORMAL] IESG, "Guidelines for the use of formal languages in IETF
|
||||
specifications",
|
||||
<http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-
|
||||
specs.txt>, 2001.
|
||||
|
||||
[X.511] International Telecommunication Union - Telecommunication
|
||||
Standardization Sector, "The Directory: Abstract Service
|
||||
Definition", X.511(1993) (also ISO/IEC 9594-3:1993).
|
||||
|
||||
[X.680] International Telecommunication Union - Telecommunication
|
||||
Standardization Sector, "Abstract Syntax Notation One
|
||||
(ASN.1) - Specification of Basic Notation", X.680(2002)
|
||||
(also ISO/IEC 8824-1:2002).
|
||||
|
||||
[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(2002) (also ISO/IEC 8825-1:2002).
|
||||
|
||||
9.2. Informative References
|
||||
|
||||
[ACID] Section 4 of ISO/IEC 10026-1:1992.
|
||||
|
||||
[GUIDE] Greenblatt, B., "LDAP Extension Style Guide", Work in
|
||||
Progress.
|
||||
|
||||
[RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation",
|
||||
RFC 3062, February 2001.
|
||||
|
||||
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
|
||||
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
|
||||
|
||||
Author's Address
|
||||
|
||||
Kurt D. Zeilenga
|
||||
OpenLDAP Foundation
|
||||
|
||||
EMail: Kurt@OpenLDAP.org
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Best Current Practice [Page 15]
|
||||
|
||||
RFC 4521 LDAP Extensions June 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights 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; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Best Current Practice [Page 16]
|
||||
|
||||
451
source/ldap_server/devdocs/rfc4522.txt
Normal file
451
source/ldap_server/devdocs/rfc4522.txt
Normal file
@ -0,0 +1,451 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group S. Legg
|
||||
Request for Comments: 4522 eB2Bcom
|
||||
Category: Standards Track June 2006
|
||||
|
||||
|
||||
Lightweight Directory Access Protocol (LDAP):
|
||||
The Binary Encoding Option
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
Each attribute stored in a Lightweight Directory Access Protocol
|
||||
(LDAP) directory has a defined syntax (i.e., data type). A syntax
|
||||
definition specifies how attribute values conforming to the syntax
|
||||
are normally represented when transferred in LDAP operations. This
|
||||
representation is referred to as the LDAP-specific encoding to
|
||||
distinguish it from other methods of encoding attribute values. This
|
||||
document defines an attribute option, the binary option, that can be
|
||||
used to specify that the associated attribute values are instead
|
||||
encoded according to the Basic Encoding Rules (BER) used by X.500
|
||||
directories.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................2
|
||||
2. Conventions .....................................................2
|
||||
3. The Binary Option ...............................................2
|
||||
4. Syntaxes Requiring Binary Transfer ..............................3
|
||||
5. Attributes Returned in a Search .................................4
|
||||
6. All User Attributes .............................................4
|
||||
7. Conflicting Requests ............................................5
|
||||
8. Security Considerations .........................................5
|
||||
9. IANA Considerations .............................................5
|
||||
10. References .....................................................5
|
||||
10.1. Normative References ......................................5
|
||||
10.2. Informative References ....................................6
|
||||
|
||||
|
||||
|
||||
|
||||
Legg Standards Track [Page 1]
|
||||
|
||||
RFC 4522 LDAP: The Binary Encoding Option June 2006
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
Each attribute stored in a Lightweight Directory Access Protocol
|
||||
(LDAP) directory [RFC4510] has a defined syntax (i.e., data type)
|
||||
which constrains the structure and format of its values.
|
||||
|
||||
The description of each syntax [RFC4517] specifies how attribute or
|
||||
assertion values [RFC4512] conforming to the syntax are normally
|
||||
represented when transferred in LDAP operations [RFC4511]. This
|
||||
representation is referred to as the LDAP-specific encoding to
|
||||
distinguish it from other methods of encoding attribute values.
|
||||
|
||||
This document defines an attribute option, the binary option, which
|
||||
can be used in an attribute description [RFC4512] in an LDAP
|
||||
operation to specify that the associated attribute values or
|
||||
assertion values are, or are requested to be, encoded according to
|
||||
the Basic Encoding Rules (BER) [BER] as used by X.500 [X.500]
|
||||
directories, instead of the usual LDAP-specific encoding.
|
||||
|
||||
The binary option was originally defined in RFC 2251 [RFC2251]. The
|
||||
LDAP technical specification [RFC4510] has obsoleted the previously
|
||||
defined LDAP technical specification [RFC3377], which included RFC
|
||||
2251. The binary option was not included in the revised LDAP
|
||||
technical specification for a variety of reasons including
|
||||
implementation inconsistencies. No attempt is made here to resolve
|
||||
the known inconsistencies.
|
||||
|
||||
This document reintroduces the binary option for use with certain
|
||||
attribute syntaxes, such as certificate syntax [RFC4523], that
|
||||
specifically require it. No attempt has been made to address use of
|
||||
the binary option with attributes of syntaxes that do not require its
|
||||
use. Unless addressed in a future specification, this use is to be
|
||||
avoided.
|
||||
|
||||
2. Conventions
|
||||
|
||||
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, RFC 2119
|
||||
[BCP14].
|
||||
|
||||
3. The Binary Option
|
||||
|
||||
The binary option is indicated with the attribute option string
|
||||
"binary" in an attribute description. Note that, like all attribute
|
||||
options, the string representing the binary option is case
|
||||
insensitive.
|
||||
|
||||
|
||||
|
||||
|
||||
Legg Standards Track [Page 2]
|
||||
|
||||
RFC 4522 LDAP: The Binary Encoding Option June 2006
|
||||
|
||||
|
||||
Where the binary option is present in an attribute description, the
|
||||
associated attribute values or assertion values MUST be BER encoded
|
||||
(otherwise the values are encoded according to the LDAP-specific
|
||||
encoding [RFC4517] for the attribute's syntax). Note that it is
|
||||
possible for a syntax to be defined such that its LDAP-specific
|
||||
encoding is exactly the same as its BER encoding.
|
||||
|
||||
In terms of the protocol [RFC4511], the binary option specifies that
|
||||
the contents octets of the associated AttributeValue or
|
||||
AssertionValue OCTET STRING are a complete BER encoding of the
|
||||
relevant value.
|
||||
|
||||
The binary option is not a tagging option [RFC4512], so the presence
|
||||
of the binary option does not specify an attribute subtype. An
|
||||
attribute description containing the binary option references exactly
|
||||
the same attribute as the attribute description without the binary
|
||||
option. The supertype/subtype relationships of attributes with
|
||||
tagging options are not altered in any way by the presence or absence
|
||||
of the binary option.
|
||||
|
||||
An attribute description SHALL be treated as unrecognized if it
|
||||
contains the binary option and the syntax of the attribute does not
|
||||
have an associated ASN.1 type [RFC4517], or the BER encoding of
|
||||
values of that type is not supported.
|
||||
|
||||
The presence or absence of the binary option only affects the
|
||||
transfer of attribute and assertion values in the protocol; servers
|
||||
store any particular attribute value in a format of their choosing.
|
||||
|
||||
4. Syntaxes Requiring Binary Transfer
|
||||
|
||||
The attribute values of certain attribute syntaxes are defined
|
||||
without an LDAP-specific encoding and are required to be transferred
|
||||
in the BER-encoded form. For the purposes of this document, these
|
||||
syntaxes are said to have a binary transfer requirement. The
|
||||
certificate, certificate list, certificate pair, and supported
|
||||
algorithm syntaxes [RFC4523] are examples of syntaxes with a binary
|
||||
transfer requirement. These syntaxes also have an additional
|
||||
requirement that the exact BER encoding must be preserved. Note that
|
||||
this is a property of the syntaxes themselves, and not a property of
|
||||
the binary option. In the absence of this requirement, LDAP clients
|
||||
would need to re-encode values using the Distinguished Encoding Rules
|
||||
(DER).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Legg Standards Track [Page 3]
|
||||
|
||||
RFC 4522 LDAP: The Binary Encoding Option June 2006
|
||||
|
||||
|
||||
5. Attributes Returned in a Search
|
||||
|
||||
An LDAP search request [RFC4511] contains a list of the attributes
|
||||
(the requested attributes list) to be returned from each entry
|
||||
matching the search filter. An attribute description in the
|
||||
requested attributes list also implicitly requests all subtypes of
|
||||
the attribute type in the attribute description, whether through
|
||||
attribute subtyping or attribute tagging option subtyping [RFC4512].
|
||||
|
||||
The requested attributes list MAY contain attribute descriptions with
|
||||
the binary option, but MUST NOT contain two attribute descriptions
|
||||
with the same attribute type and the same tagging options (even if
|
||||
only one of them has the binary option). The binary option in an
|
||||
attribute description in the requested attributes list implicitly
|
||||
applies to all the subtypes of the attribute type in the attribute
|
||||
description (however, see Section 7).
|
||||
|
||||
Attributes of a syntax with the binary transfer requirement, if
|
||||
returned, SHALL be returned in the binary form (i.e., with the binary
|
||||
option in the attribute description and the associated attribute
|
||||
values BER encoded) regardless of whether the binary option was
|
||||
present in the request (for the attribute or for one of its
|
||||
supertypes).
|
||||
|
||||
Attributes of a syntax without the binary transfer requirement, if
|
||||
returned, SHOULD be returned in the form explicitly requested. That
|
||||
is, if the attribute description in the requested attributes list
|
||||
contains the binary option, then the corresponding attribute in the
|
||||
result SHOULD be in the binary form. If the attribute description in
|
||||
the request does not contain the binary option, then the
|
||||
corresponding attribute in the result SHOULD NOT be in the binary
|
||||
form. A server MAY omit an attribute from the result if it does not
|
||||
support the requested encoding.
|
||||
|
||||
Regardless of the encoding chosen, a particular attribute value is
|
||||
returned at most once.
|
||||
|
||||
6. All User Attributes
|
||||
|
||||
If the list of attributes in a search request is empty or contains
|
||||
the special attribute description string "*", then all user
|
||||
attributes are requested to be returned.
|
||||
|
||||
Attributes of a syntax with the binary transfer requirement, if
|
||||
returned, SHALL be returned in the binary form.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Legg Standards Track [Page 4]
|
||||
|
||||
RFC 4522 LDAP: The Binary Encoding Option June 2006
|
||||
|
||||
|
||||
Attributes of a syntax without the binary transfer requirement and
|
||||
having a defined LDAP-specific encoding SHOULD NOT be returned in the
|
||||
binary form.
|
||||
|
||||
Attributes of a syntax without the binary transfer requirement and
|
||||
without a defined LDAP-specific encoding may be returned in the
|
||||
binary form or omitted from the result.
|
||||
|
||||
7. Conflicting Requests
|
||||
|
||||
A particular attribute could be explicitly requested by an attribute
|
||||
description and/or implicitly requested by the attribute descriptions
|
||||
of one or more of its supertypes, or by the special attribute
|
||||
description string "*". If the binary option is present in at least
|
||||
one, but not all, of these attribute descriptions then the effect of
|
||||
the request with respect to binary transfer is implementation
|
||||
defined.
|
||||
|
||||
8. Security Considerations
|
||||
|
||||
When interpreting security-sensitive fields, and in particular fields
|
||||
used to grant or deny access, implementations MUST ensure that any
|
||||
matching rule comparisons are done on the underlying abstract value,
|
||||
regardless of the particular encoding used.
|
||||
|
||||
9. IANA Considerations
|
||||
|
||||
The Internet Assigned Numbers Authority (IANA) has updated the LDAP
|
||||
attribute description option registry [BCP64] as indicated by the
|
||||
following template:
|
||||
|
||||
Subject:
|
||||
Request for LDAP Attribute Description Option Registration
|
||||
Option Name: binary
|
||||
Family of Options: NO
|
||||
Person & email address to contact for further information:
|
||||
Steven Legg <steven.legg@eb2bcom.com>
|
||||
Specification: RFC 4522
|
||||
Author/Change Controller: IESG
|
||||
|
||||
10. References
|
||||
|
||||
10.1. Normative References
|
||||
|
||||
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Legg Standards Track [Page 5]
|
||||
|
||||
RFC 4522 LDAP: The Binary Encoding Option June 2006
|
||||
|
||||
|
||||
[BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
|
||||
Considerations for the Lightweight Directory Access
|
||||
Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
|
||||
|
||||
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
|
||||
(LDAP): Technical Specification Road Map", RFC 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, June
|
||||
2006.
|
||||
|
||||
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
|
||||
(LDAP): Syntaxes and Matching Rules", RFC 4517, June
|
||||
2006.
|
||||
|
||||
[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
|
||||
(LDAP) Schema Definitions for X.509 Certificates", RFC
|
||||
4523, June 2006.
|
||||
|
||||
[BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
|
||||
Information Technology - ASN.1 encoding rules:
|
||||
Specification of Basic Encoding Rules (BER), Canonical
|
||||
Encoding Rules (CER) and Distinguished Encoding Rules
|
||||
(DER).
|
||||
|
||||
10.2. Informative References
|
||||
|
||||
[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
|
||||
Access Protocol (v3)", RFC 2251, December 1997.
|
||||
|
||||
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
|
||||
Protocol (v3): Technical Specification", RFC 3377,
|
||||
September 2002.
|
||||
|
||||
[X.500] ITU-T Recommendation X.500 (02/01) | ISO/IEC 9594-1:2001,
|
||||
Information technology - Open Systems Interconnection -
|
||||
The Directory: Overview of concepts, models and services
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Legg Standards Track [Page 6]
|
||||
|
||||
RFC 4522 LDAP: The Binary Encoding Option June 2006
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
Dr. Steven Legg
|
||||
eB2Bcom
|
||||
Suite 3, Woodhouse Corporate Centre
|
||||
935 Station Street
|
||||
Box Hill North, Victoria 3129
|
||||
AUSTRALIA
|
||||
|
||||
Phone: +61 3 9896 7830
|
||||
Fax: +61 3 9896 7801
|
||||
EMail: steven.legg@eb2bcom.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Legg Standards Track [Page 7]
|
||||
|
||||
RFC 4522 LDAP: The Binary Encoding Option June 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights 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; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Legg Standards Track [Page 8]
|
||||
|
||||
1347
source/ldap_server/devdocs/rfc4523.txt
Normal file
1347
source/ldap_server/devdocs/rfc4523.txt
Normal file
File diff suppressed because it is too large
Load Diff
1403
source/ldap_server/devdocs/rfc4524.txt
Normal file
1403
source/ldap_server/devdocs/rfc4524.txt
Normal file
File diff suppressed because it is too large
Load Diff
339
source/ldap_server/devdocs/rfc4525.txt
Normal file
339
source/ldap_server/devdocs/rfc4525.txt
Normal file
@ -0,0 +1,339 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group K. Zeilenga
|
||||
Request for Comments: 4525 OpenLDAP Foundation
|
||||
Category: Informational June 2006
|
||||
|
||||
|
||||
Lightweight Directory Access Protocol (LDAP)
|
||||
Modify-Increment Extension
|
||||
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This memo provides information for the Internet community. It does
|
||||
not specify an Internet standard of any kind. Distribution of this
|
||||
memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes an extension to the Lightweight Directory
|
||||
Access Protocol (LDAP) Modify operation to support an increment
|
||||
capability. This extension is useful in provisioning applications,
|
||||
especially when combined with the assertion control and/or the pre-
|
||||
read or post-read control extension.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Background and Intended Use .....................................1
|
||||
2. The Modify-Increment Extension ..................................2
|
||||
3. LDIF Support ....................................................2
|
||||
4. Security Considerations .........................................3
|
||||
5. IANA Considerations .............................................3
|
||||
5.1. Object Identifier ..........................................3
|
||||
5.2. LDAP Protocol Mechanism ....................................3
|
||||
5.3. LDAP Protocol Mechanism ....................................4
|
||||
6. References ......................................................4
|
||||
6.1. Normative References .......................................4
|
||||
6.2. Informative References .....................................5
|
||||
|
||||
1. Background and Intended Use
|
||||
|
||||
The Lightweight Directory Access Protocol (LDAP) [RFC4510] does not
|
||||
currently provide an operation to increment values of an attribute.
|
||||
A client must read the values of the attribute and then modify those
|
||||
values to increment them by the desired amount. As the values may be
|
||||
updated by other clients between this add and modify, the client must
|
||||
|
||||
|
||||
|
||||
Zeilenga Informational [Page 1]
|
||||
|
||||
RFC 4525 LDAP Modify-Increment Extension June 2006
|
||||
|
||||
|
||||
be careful to construct the modify request so that it fails in this
|
||||
case, and upon failure, to re-read the values and construct a new
|
||||
modify request.
|
||||
|
||||
This document extends the LDAP Modify Operation [RFC4511] to support
|
||||
an increment values capability. This feature is intended to be used
|
||||
with either the LDAP pre-read or post-read control extensions
|
||||
[RFC4527]. This feature may also be used with the LDAP assertion
|
||||
control extension [RFC4528] to provide test-and-increment
|
||||
functionality.
|
||||
|
||||
In this document key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
|
||||
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
|
||||
"OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119].
|
||||
|
||||
2. The Modify-Increment Extension
|
||||
|
||||
This document extends the LDAP Modify request to support a increment
|
||||
values capability. Implementations of this extension SHALL support
|
||||
an additional ModifyRequest operation enumeration value increment
|
||||
(3), as described herein. Implementations not supporting this
|
||||
extension will treat this value as they would an unlisted value,
|
||||
e.g., as a protocol error.
|
||||
|
||||
The increment (3) operation value specifies that an increment values
|
||||
modification is requested. All existing values of the modification
|
||||
attribute are to be incremented by the listed value. The
|
||||
modification attribute must be appropriate for the request (e.g., it
|
||||
must have INTEGER or other increment-able values), and the
|
||||
modification must provide one and only one value. If the attribute
|
||||
is not appropriate for the request, a constraintViolation or other
|
||||
appropriate error is to be returned. If multiple values are
|
||||
provided, a protocolError is to be returned.
|
||||
|
||||
Servers supporting this feature SHOULD publish the object identifier
|
||||
(OID) 1.3.6.1.1.14 as a value of the 'supportedFeatures' [RFC4512]
|
||||
attribute in the root DSE. Clients supporting this feature SHOULD
|
||||
NOT use the feature unless they know the server supports it.
|
||||
|
||||
3. LDIF Support
|
||||
|
||||
To represent Modify-Increment requests in LDAP Data Interchange
|
||||
Format [RFC2849], the ABNF [RFC4234] production <mod-spec> is
|
||||
extended as follows:
|
||||
|
||||
mod-spec =/ "increment:" FILL AttributeDescription SEP
|
||||
attrval-spec "-" SEP
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Informational [Page 2]
|
||||
|
||||
RFC 4525 LDAP Modify-Increment Extension June 2006
|
||||
|
||||
|
||||
For example,
|
||||
|
||||
# Increment uidNumber
|
||||
dn: cn=max-assigned uidNumber,dc=example,dc=com
|
||||
changetype: modify
|
||||
increment: uidNumber
|
||||
uidNumber: 1
|
||||
-
|
||||
|
||||
This LDIF fragment represents a Modify request to increment the
|
||||
value(s) of uidNumber by 1.
|
||||
|
||||
4. Security Considerations
|
||||
|
||||
General LDAP security considerations [RFC4510], as well as those
|
||||
specific to the LDAP Modify [RFC4511], apply to this Modify-Increment
|
||||
extension. Beyond these considerations, it is noted that
|
||||
introduction of this extension should reduce application complexity
|
||||
(by providing one operation for what presently requires multiple
|
||||
operations) and, hence, it may aid in the production of correct and
|
||||
secure implementations.
|
||||
|
||||
5. IANA Considerations
|
||||
|
||||
Registration of the following values [RFC4520] have been completed.
|
||||
|
||||
5.1. Object Identifier
|
||||
|
||||
The IANA has assigned an LDAP Object Identifier to identify the LDAP
|
||||
Modify-Increment feature, as 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 4525
|
||||
Author/Change Controller: Author
|
||||
Comments:
|
||||
Identifies the LDAP Modify-Increment feature
|
||||
|
||||
5.2. LDAP Protocol Mechanism
|
||||
|
||||
The following LDAP Protocol Mechanism has been registered.
|
||||
|
||||
Subject: Request for LDAP Protocol Mechanism Registration
|
||||
Object Identifier: 1.3.6.1.1.14
|
||||
Description: Modify-Increment
|
||||
Person & email address to contact for further information:
|
||||
Kurt Zeilenga <kurt@openldap.org>
|
||||
|
||||
|
||||
|
||||
Zeilenga Informational [Page 3]
|
||||
|
||||
RFC 4525 LDAP Modify-Increment Extension June 2006
|
||||
|
||||
|
||||
Usage: Feature
|
||||
Specification: RFC 4525
|
||||
Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
|
||||
Comments: none
|
||||
|
||||
5.3. LDAP Protocol Mechanism
|
||||
|
||||
The IANA has assigned an LDAP ModifyRequest Operation Type (3)
|
||||
[RFC4520] for use in this document.
|
||||
|
||||
Subject: Request for LDAP Protocol Mechanism Registration
|
||||
ModifyRequest Operation Name: increment
|
||||
Description: Modify-Increment
|
||||
Person & email address to contact for further information:
|
||||
Kurt Zeilenga <kurt@openldap.org>
|
||||
Usage: Feature
|
||||
Specification: RFC 4525
|
||||
Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
|
||||
Comments: none
|
||||
|
||||
6. References
|
||||
|
||||
6.1. Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
||||
Specifications: ABNF", RFC 4234, October 2005.
|
||||
|
||||
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
|
||||
Technical Specification", RFC 2849, June 2000.
|
||||
|
||||
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
|
||||
Protocol (LDAP): Technical Specification Road Map", RFC
|
||||
4510, June 2006.
|
||||
|
||||
[RFC4511] Sermersheim, J., Ed., "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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Informational [Page 4]
|
||||
|
||||
RFC 4525 LDAP Modify-Increment Extension June 2006
|
||||
|
||||
|
||||
6.2. Informative References
|
||||
|
||||
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
|
||||
(IANA) Considerations for the Lightweight Directory
|
||||
Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
|
||||
|
||||
[RFC4527] Zeilenga, K., "Lightweight Directory Access Protocol
|
||||
(LDAP) Read Entry Controls", RFC 4527, June 2006.
|
||||
|
||||
[RFC4528] Zeilenga, K., "Lightweight Directory Access Protocol
|
||||
(LDAP) Assertion Control", RFC 4528, June 2006.
|
||||
|
||||
Author's Address
|
||||
|
||||
Kurt D. Zeilenga
|
||||
OpenLDAP Foundation
|
||||
|
||||
EMail: Kurt@OpenLDAP.org
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Informational [Page 5]
|
||||
|
||||
RFC 4525 LDAP Modify-Increment Extension June 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights 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; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Informational [Page 6]
|
||||
|
||||
283
source/ldap_server/devdocs/rfc4526.txt
Normal file
283
source/ldap_server/devdocs/rfc4526.txt
Normal file
@ -0,0 +1,283 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group K. Zeilenga
|
||||
Request for Comments: 4526 OpenLDAP Foundation
|
||||
Category: Standards Track June 2006
|
||||
|
||||
|
||||
Lightweight Directory Access Protocol (LDAP)
|
||||
Absolute True and False Filters
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
This document extends the Lightweight Directory Access Protocol
|
||||
(LDAP) to support absolute True and False filters based upon similar
|
||||
capabilities found in X.500 directory systems. The document also
|
||||
extends the String Representation of LDAP Search Filters to support
|
||||
these filters.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Background ......................................................1
|
||||
2. Absolute True and False Filters .................................2
|
||||
3. Security Considerations .........................................2
|
||||
4. IANA Considerations .............................................3
|
||||
5. References ......................................................3
|
||||
5.1. Normative References .......................................3
|
||||
5.2. Informative References .....................................3
|
||||
|
||||
1. Background
|
||||
|
||||
The X.500 Directory Access Protocol (DAP) [X.511] supports absolute
|
||||
True and False assertions. An 'and' filter with zero elements always
|
||||
evaluates to True. An 'or' filter with zero elements always
|
||||
evaluates to False. These filters are commonly used when requesting
|
||||
DSA-specific Entries (DSEs) that do not necessarily have
|
||||
'objectClass' attributes; that is, where "(objectClass=*)" may
|
||||
evaluate to False.
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 1]
|
||||
|
||||
RFC 4526 LDAP Absolute True and False Filters June 2006
|
||||
|
||||
|
||||
Although LDAPv2 [RFC1777][RFC3494] placed no restriction on the
|
||||
number of elements in 'and' and 'or' filter sets, the LDAPv2 string
|
||||
representation [RFC1960][RFC3494] could not represent empty 'and' and
|
||||
'or' filter sets. Due to this, absolute True or False filters were
|
||||
(unfortunately) eliminated from LDAPv3 [RFC4510].
|
||||
|
||||
This documents extends LDAPv3 to support absolute True and False
|
||||
assertions by allowing empty 'and' and 'or' in Search filters
|
||||
[RFC4511] and extends the filter string representation [RFC4515] to
|
||||
allow empty filter lists.
|
||||
|
||||
It is noted that certain search operations, such as those used to
|
||||
retrieve subschema information [RFC4512], require use of particular
|
||||
filters. This document does not change these requirements.
|
||||
|
||||
This feature is intended to allow a more direct mapping between DAP
|
||||
and LDAP (as needed to implement DAP-to-LDAP gateways).
|
||||
|
||||
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
|
||||
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
|
||||
and "OPTIONAL" are to be interpreted as described in BCP 14
|
||||
[RFC2119].
|
||||
|
||||
2. Absolute True and False Filters
|
||||
|
||||
Implementations of this extension SHALL allow 'and' and 'or' choices
|
||||
with zero filter elements.
|
||||
|
||||
An 'and' filter consisting of an empty set of filters SHALL evaluate
|
||||
to True. This filter is represented by the string "(&)".
|
||||
|
||||
An 'or' filter consisting of an empty set of filters SHALL evaluate
|
||||
to False. This filter is represented by the string "(|)".
|
||||
|
||||
Servers supporting this feature SHOULD publish the Object Identifier
|
||||
1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures'
|
||||
[RFC4512] attribute in the root DSE.
|
||||
|
||||
Clients supporting this feature SHOULD NOT use the feature unless
|
||||
they know that the server supports it.
|
||||
|
||||
3. Security Considerations
|
||||
|
||||
The (re)introduction of absolute True and False filters is not
|
||||
believed to raise any new security considerations.
|
||||
|
||||
Implementors of this (or any) LDAPv3 extension should be familiar
|
||||
with general LDAPv3 security considerations [RFC4510].
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 2]
|
||||
|
||||
RFC 4526 LDAP Absolute True and False Filters June 2006
|
||||
|
||||
|
||||
4. IANA Considerations
|
||||
|
||||
Registration of this feature has been completed by the IANA
|
||||
[RFC4520].
|
||||
|
||||
Subject: Request for LDAP Protocol Mechanism Registration Object
|
||||
Identifier: 1.3.6.1.4.1.4203.1.5.3 Description: True/False filters
|
||||
Person & email address to contact for further information:
|
||||
Kurt Zeilenga <kurt@openldap.org> Usage: Feature Specification:
|
||||
RFC 4526 Author/Change Controller: IESG Comments: none
|
||||
|
||||
This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
|
||||
IANA-assigned private enterprise allocation [PRIVATE], for use in
|
||||
this specification.
|
||||
|
||||
5. References
|
||||
|
||||
5.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., Ed, "Lightweight Directory Access
|
||||
Protocol (LDAP): Technical Specification Road Map", RFC
|
||||
4510, June 2006.
|
||||
|
||||
[RFC4511] Sermersheim, J., Ed., "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.
|
||||
|
||||
[RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory
|
||||
Access Protocol (LDAP): String Representation of Search
|
||||
Filters", RFC 4515, June 2006.
|
||||
|
||||
5.2. Informative References
|
||||
|
||||
[RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight
|
||||
Directory Access Protocol", RFC 1777, March 1995.
|
||||
|
||||
[RFC1960] Howes, T., "A String Representation of LDAP Search
|
||||
Filters", RFC 1960, June 1996.
|
||||
|
||||
[RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
|
||||
version 2 (LDAPv2) to Historic Status", RFC 3494, March
|
||||
2003.
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 3]
|
||||
|
||||
RFC 4526 LDAP Absolute True and False Filters June 2006
|
||||
|
||||
|
||||
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
|
||||
(IANA) Considerations for the Lightweight Directory
|
||||
Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
|
||||
|
||||
[X.500] International Telecommunication Union -
|
||||
Telecommunication Standardization Sector, "The
|
||||
Directory -- Overview of concepts, models and
|
||||
services," X.500(1993) (also ISO/IEC 9594-1:1994).
|
||||
|
||||
[X.501] International Telecommunication Union -
|
||||
Telecommunication Standardization Sector, "The
|
||||
Directory -- Models," X.501(1993) (also ISO/IEC 9594-
|
||||
2:1994).
|
||||
|
||||
[X.511] International Telecommunication Union -
|
||||
Telecommunication Standardization Sector, "The
|
||||
Directory: Abstract Service Definition", X.511(1993)
|
||||
(also ISO/IEC 9594-3:1993).
|
||||
|
||||
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
|
||||
http://www.openldap.org/foundation/oid-delegate.txt.
|
||||
|
||||
[PRIVATE] IANA, "Private Enterprise Numbers",
|
||||
http://www.iana.org/assignments/enterprise-numbers.
|
||||
|
||||
Author's Address
|
||||
|
||||
Kurt D. Zeilenga
|
||||
OpenLDAP Foundation
|
||||
|
||||
EMail: Kurt@OpenLDAP.org
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 4]
|
||||
|
||||
RFC 4526 LDAP Absolute True and False Filters June 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights 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; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 5]
|
||||
|
||||
451
source/ldap_server/devdocs/rfc4527.txt
Normal file
451
source/ldap_server/devdocs/rfc4527.txt
Normal file
@ -0,0 +1,451 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group K. Zeilenga
|
||||
Request for Comments: 4527 OpenLDAP Foundation
|
||||
Category: Standards Track June 2006
|
||||
|
||||
|
||||
Lightweight Directory Access Protocol (LDAP)
|
||||
Read Entry Controls
|
||||
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
This document specifies an extension to the Lightweight Directory
|
||||
Access Protocol (LDAP) to allow the client to read the target entry
|
||||
of an update operation. The client may request to read the entry
|
||||
before and/or after the modifications are applied. These reads are
|
||||
done as an atomic part of the update operation.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Background and Intent of Use ....................................2
|
||||
2. Terminology .....................................................2
|
||||
3. Read Entry Controls .............................................3
|
||||
3.1. The Pre-Read Controls ......................................3
|
||||
3.2. The Post-Read Controls .....................................3
|
||||
4. Interaction with Other Controls .................................4
|
||||
5. Security Considerations .........................................4
|
||||
6. IANA Considerations .............................................5
|
||||
6.1. Object Identifier ..........................................5
|
||||
6.2. LDAP Protocol Mechanisms ...................................5
|
||||
7. Acknowledgement .................................................5
|
||||
8. References ......................................................6
|
||||
8.1. Normative References .......................................6
|
||||
8.2. Informative References .....................................7
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 1]
|
||||
|
||||
RFC 4527 LDAP Read Entry Controls June 2006
|
||||
|
||||
|
||||
1. Background and Intent of Use
|
||||
|
||||
This document specifies an extension to the Lightweight Directory
|
||||
Access Protocol (LDAP) [RFC4510] to allow the client to read the
|
||||
target entry of an update operation (e.g., Add, Delete, Modify,
|
||||
ModifyDN). The extension utilizes controls [RFC4511] attached to
|
||||
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.
|
||||
|
||||
To ensure proper isolation, the controls are processed as an atomic
|
||||
part of the update operation.
|
||||
|
||||
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' [RFC4530] and 'modifyTimestamp'
|
||||
[RFC4512] 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 [RFC4511].
|
||||
|
||||
DN stands for Distinguished Name.
|
||||
DSA stands for Directory System Agent (i.e., a directory server).
|
||||
DSE stands for DSA-specific Entry.
|
||||
|
||||
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
|
||||
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
|
||||
and "OPTIONAL" are to be interpreted as described in BCP 14
|
||||
[RFC2119].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 2]
|
||||
|
||||
RFC 4527 LDAP Read Entry Controls June 2006
|
||||
|
||||
|
||||
3. Read Entry Controls
|
||||
|
||||
3.1. The Pre-Read Controls
|
||||
|
||||
The Pre-Read request and response controls are identified by the
|
||||
1.3.6.1.1.13.1 object identifier. Servers implementing these
|
||||
controls SHOULD publish 1.3.6.1.1.13.1 as a value of the
|
||||
'supportedControl' [RFC4512] in their root DSE.
|
||||
|
||||
The Pre-Read request control is a LDAP Control [RFC4511] whose
|
||||
controlType is 1.3.6.1.1.13.1 and whose controlValue is a BER-encoded
|
||||
AttributeSelection [RFC4511], as extended by [RFC3673]. 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 1.3.6.1.1.13.1 and whose 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 the target
|
||||
entry prior to the application of the update. The AttributeSelection
|
||||
indicates, as discussed in [RFC4511][RFC3673], which attributes are
|
||||
requested to appear in the copy. 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 (in either normal or control
|
||||
processing), no Pre-Read response control is provided.
|
||||
|
||||
3.2. The Post-Read Controls
|
||||
|
||||
The Post-Read request and response controls are identified by the
|
||||
1.3.6.1.1.13.2 object identifier. Servers implementing these
|
||||
controls SHOULD publish 1.3.6.1.1.13.2 as a value of the
|
||||
'supportedControl' [RFC4512] in their root DSE.
|
||||
|
||||
The Post-Read request control is a LDAP Control [RFC4511] whose
|
||||
controlType is 1.3.6.1.1.13.2 and whose controlValue, an OCTET
|
||||
STRING, contains a BER-encoded AttributeSelection [RFC4511], as
|
||||
extended by [RFC3673]. The criticality may be TRUE or FALSE. This
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 3]
|
||||
|
||||
RFC 4527 LDAP Read Entry Controls June 2006
|
||||
|
||||
|
||||
control is appropriate for the addRequest, modifyRequest, and
|
||||
modDNRequest LDAP messages.
|
||||
|
||||
The corresponding response control is a LDAP Control whose
|
||||
controlType is 1.3.6.1.1.13.2 and whose controlValue is a BER-encoded
|
||||
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 the target
|
||||
entry after the application of the update. The AttributeSelection
|
||||
indicates, as discussed in [RFC4511][RFC3673], which attributes are
|
||||
requested to appear in the copy. 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 (in either normal or control
|
||||
processing), no Post-Read response control is provided.
|
||||
|
||||
4. Interaction with Other Controls
|
||||
|
||||
The Pre-Read and Post-Read controls may be combined with each other
|
||||
and/or with a variety of other controls. When combined with the
|
||||
assertion control [RFC4528] and/or the manageDsaIT control [RFC3296],
|
||||
the semantics of each control included in the combination applies.
|
||||
The Pre-Read 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 for reading of the information provided in this control
|
||||
and that the client is authorized to perform the requested directory
|
||||
update.
|
||||
|
||||
Security considerations for the update operations [RFC4511] extended
|
||||
by this control, as well as general LDAP security considerations
|
||||
[RFC4510], generally apply to implementation and use of this
|
||||
extension
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 4]
|
||||
|
||||
RFC 4527 LDAP Read Entry Controls June 2006
|
||||
|
||||
|
||||
6. IANA Considerations
|
||||
|
||||
Registration of the following protocol values [RFC4520] have been
|
||||
completed by the IANA.
|
||||
|
||||
6.1. Object Identifier
|
||||
|
||||
The IANA has registered 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 4527
|
||||
Author/Change Controller: IESG
|
||||
Comments: Identifies the LDAP Read Entry Controls
|
||||
|
||||
6.2. LDAP Protocol Mechanisms
|
||||
|
||||
The IANA has registered the LDAP Protocol Mechanism described in this
|
||||
document.
|
||||
|
||||
Subject: Request for LDAP Protocol Mechanism Registration
|
||||
Object Identifier: 1.3.6.1.1.13.1
|
||||
Description: LDAP Pre-read Control
|
||||
Person & email address to contact for further information:
|
||||
Kurt Zeilenga <kurt@openldap.org>
|
||||
Usage: Control
|
||||
Specification: RFC 4527
|
||||
Author/Change Controller: IESG
|
||||
Comments: none
|
||||
|
||||
Subject: Request for LDAP Protocol Mechanism Registration
|
||||
Object Identifier: 1.3.6.1.1.13.2
|
||||
Description: LDAP Post-read Control
|
||||
Person & email address to contact for further information:
|
||||
Kurt Zeilenga <kurt@openldap.org>
|
||||
Usage: Control
|
||||
Specification: RFC 4527
|
||||
Author/Change Controller: IESG
|
||||
Comments: none
|
||||
|
||||
7. Acknowledgement
|
||||
|
||||
The LDAP Pre-Read and Post-Read controls are modeled after similar
|
||||
capabilities offered in the DAP [X.511].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 5]
|
||||
|
||||
RFC 4527 LDAP Read Entry Controls June 2006
|
||||
|
||||
|
||||
8. References
|
||||
|
||||
8.1. Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC3296] Zeilenga, K., "Named Subordinate References in
|
||||
Lightweight Directory Access Protocol (LDAP)
|
||||
Directories", RFC 3296, July 2002.
|
||||
|
||||
[RFC3673] Zeilenga, K., "Lightweight Directory Access Protocol
|
||||
version 3 (LDAPv3): All Operational Attributes", RFC
|
||||
3673, December 2003.
|
||||
|
||||
[RFC4510] Zeilenga, K., Ed, "Lightweight Directory Access
|
||||
Protocol (LDAP): Technical Specification Road Map", RFC
|
||||
4510, June 2006.
|
||||
|
||||
[RFC4511] Sermersheim, J., Ed., "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.
|
||||
|
||||
[RFC4528] Zeilenga, K., "Lightweight Directory Access Protocol
|
||||
(LDAP) Assertion Control", RFC 4528, June 2006.
|
||||
|
||||
[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).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 6]
|
||||
|
||||
RFC 4527 LDAP Read Entry Controls June 2006
|
||||
|
||||
|
||||
8.2. Informative References
|
||||
|
||||
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
|
||||
(IANA) Considerations for the Lightweight Directory
|
||||
Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
|
||||
|
||||
[RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol
|
||||
(LDAP) EntryUUID Operational Attribute", RFC 4530, June
|
||||
2006.
|
||||
|
||||
[X.511] International Telecommunication Union -
|
||||
Telecommunication Standardization Sector, "The
|
||||
Directory: Abstract Service Definition", X.511(1993)
|
||||
(also ISO/IEC 9594-3:1993).
|
||||
|
||||
Author's Address
|
||||
|
||||
Kurt D. Zeilenga
|
||||
OpenLDAP Foundation
|
||||
|
||||
EMail: Kurt@OpenLDAP.org
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 7]
|
||||
|
||||
RFC 4527 LDAP Read Entry Controls June 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights 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; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 8]
|
||||
|
||||
339
source/ldap_server/devdocs/rfc4528.txt
Normal file
339
source/ldap_server/devdocs/rfc4528.txt
Normal file
@ -0,0 +1,339 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group K. Zeilenga
|
||||
Request for Comments: 4528 OpenLDAP Foundation
|
||||
Category: Standards Track June 2006
|
||||
|
||||
|
||||
Lightweight Directory Access Protocol (LDAP)
|
||||
Assertion Control
|
||||
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
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 an assertion applied
|
||||
to the target entry of the operation is true. It can be used to
|
||||
construct "test and set", "test and clear", and other conditional
|
||||
operations.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Overview ........................................................2
|
||||
2. Terminology .....................................................2
|
||||
3. The Assertion Control ...........................................2
|
||||
4. Security Considerations .........................................3
|
||||
5. IANA Considerations .............................................4
|
||||
5.1. Object Identifier ..........................................4
|
||||
5.2. LDAP Protocol Mechanism ....................................4
|
||||
5.3. LDAP Result Code ...........................................4
|
||||
6. Acknowledgements ................................................5
|
||||
7. References ......................................................5
|
||||
7.1. Normative References .......................................5
|
||||
7.2. Informative References .....................................5
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 1]
|
||||
|
||||
RFC 4528 LDAP Assertion Control June 2006
|
||||
|
||||
|
||||
1. Overview
|
||||
|
||||
This document defines the Lightweight Directory Access Protocol
|
||||
(LDAP) [RFC4510] assertion control. The assertion control allows the
|
||||
client to specify a condition that must be true for the operation to
|
||||
be processed normally. Otherwise, the operation is not performed.
|
||||
For instance, the control can be used with the Modify operation
|
||||
[RFC4511] to perform atomic "test and set" and "test and clear"
|
||||
operations.
|
||||
|
||||
The control may be attached to any update operation to support
|
||||
conditional addition, deletion, modification, and renaming of the
|
||||
target object. The asserted condition is evaluated as an integral
|
||||
part the operation.
|
||||
|
||||
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 that match 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] 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 [RFC4511].
|
||||
|
||||
DSA stands for Directory System Agent (or server).
|
||||
DSE stands for DSA-specific Entry.
|
||||
|
||||
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
|
||||
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
|
||||
and "OPTIONAL" are to be interpreted as described in BCP 14
|
||||
[RFC2119].
|
||||
|
||||
3. The Assertion Control
|
||||
|
||||
The assertion control is an LDAP Control [RFC4511] whose controlType
|
||||
is 1.3.6.1.1.12 and whose controlValue is a BER-encoded Filter
|
||||
[Protocol, Section 4.5.1]. The criticality may be TRUE or FALSE.
|
||||
There is no corresponding response control.
|
||||
|
||||
The control is appropriate for both LDAP interrogation and update
|
||||
operations [RFC4511], including Add, Compare, Delete, Modify,
|
||||
ModifyDN (rename), and Search. It is inappropriate for Abandon,
|
||||
Bind, Unbind, and StartTLS operations.
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 2]
|
||||
|
||||
RFC 4528 LDAP Assertion Control June 2006
|
||||
|
||||
|
||||
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 or Undefined, then assertionFailed (122)
|
||||
resultCode is returned, and no further processing is performed.
|
||||
|
||||
For Add, Compare, and ModifyDN operations, the target is indicated by
|
||||
the entry field in the request. For Modify operations, the target is
|
||||
indicated by the object field. For Delete operations, the target is
|
||||
indicated by the DelRequest type. For Compare operations 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 of the operation SHALL be done as
|
||||
one atomic action.
|
||||
|
||||
For Search operations, the target is indicated by the baseObject
|
||||
field, and the evaluation is done after "finding" but before
|
||||
"searching" [RFC4511]. Hence, no entries or continuations references
|
||||
are returned if the assertion fails.
|
||||
|
||||
Servers implementing this technical specification SHOULD publish the
|
||||
object identifier 1.3.6.1.1.12 as a value of the 'supportedControl'
|
||||
attribute [RFC4512] in their root DSE. A server MAY choose to
|
||||
advertise this extension only when the client is authorized to use
|
||||
it.
|
||||
|
||||
Other documents may specify how this control applies to other LDAP
|
||||
operations. In doing so, they must state how the target entry is
|
||||
determined.
|
||||
|
||||
4. Security Considerations
|
||||
|
||||
The filter may, like other components of the request, contain
|
||||
sensitive information. When it does, this information should be
|
||||
appropriately protected.
|
||||
|
||||
As with any general assertion mechanism, the mechanism can be used to
|
||||
determine directory content. Hence, this mechanism SHOULD be subject
|
||||
to appropriate access controls.
|
||||
|
||||
Some assertions may be very complex, requiring significant time and
|
||||
resources to evaluate. Hence, this mechanism SHOULD be subject to
|
||||
appropriate administrative controls.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 3]
|
||||
|
||||
RFC 4528 LDAP Assertion Control June 2006
|
||||
|
||||
|
||||
Security considerations for the base operations [RFC4511] extended by
|
||||
this control, as well as general LDAP security considerations
|
||||
[RFC4510], generally apply to implementation and use of this
|
||||
extension.
|
||||
|
||||
5. IANA Considerations
|
||||
|
||||
5.1. Object Identifier
|
||||
|
||||
The IANA has assigned an LDAP Object Identifier [RFC4520] 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 4528
|
||||
Author/Change Controller: IESG
|
||||
Comments:
|
||||
Identifies the LDAP Assertion Control
|
||||
|
||||
5.2. LDAP Protocol Mechanism
|
||||
|
||||
Registration of this protocol mechanism [RFC4520] is requested.
|
||||
|
||||
Subject: Request for LDAP Protocol Mechanism Registration
|
||||
Object Identifier: 1.3.6.1.1.12
|
||||
Description: Assertion Control
|
||||
Person & email address to contact for further information:
|
||||
Kurt Zeilenga <kurt@openldap.org>
|
||||
Usage: Control
|
||||
Specification: RFC 4528
|
||||
Author/Change Controller: IESG
|
||||
Comments: none
|
||||
|
||||
5.3. LDAP Result Code
|
||||
|
||||
The IANA has assigned an LDAP Result Code [RFC4520] called
|
||||
'assertionFailed' (122).
|
||||
|
||||
Subject: LDAP Result Code Registration
|
||||
Person & email address to contact for further information:
|
||||
Kurt Zeilenga <kurt@OpenLDAP.org>
|
||||
Result Code Name: assertionFailed
|
||||
Specification: RFC 4528
|
||||
Author/Change Controller: IESG
|
||||
Comments: none
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 4]
|
||||
|
||||
RFC 4528 LDAP Assertion Control June 2006
|
||||
|
||||
|
||||
6. Acknowledgements
|
||||
|
||||
The assertion control concept is attributed to Morteza Ansari.
|
||||
|
||||
7. References
|
||||
|
||||
7.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., Ed., "Lightweight Directory Access
|
||||
Protocol (LDAP): Technical Specification Road Map", RFC
|
||||
4510, June 2006.
|
||||
|
||||
[RFC4511] Sermersheim, J., Ed., "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.
|
||||
|
||||
[X.680] International Telecommunication Union -
|
||||
Telecommunication Standardization Sector, "Abstract
|
||||
Syntax Notation One (ASN.1) - Specification of Basic
|
||||
Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
|
||||
|
||||
[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(2002) (also
|
||||
ISO/IEC 8825-1:2002).
|
||||
|
||||
7.2. Informative References
|
||||
|
||||
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
|
||||
(IANA) Considerations for the Lightweight Directory
|
||||
Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
|
||||
|
||||
Author's Address
|
||||
|
||||
Kurt D. Zeilenga
|
||||
OpenLDAP Foundation
|
||||
|
||||
EMail: Kurt@OpenLDAP.org
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 5]
|
||||
|
||||
RFC 4528 LDAP Assertion Control June 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights 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; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 6]
|
||||
|
||||
339
source/ldap_server/devdocs/rfc4529.txt
Normal file
339
source/ldap_server/devdocs/rfc4529.txt
Normal file
@ -0,0 +1,339 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group K. Zeilenga
|
||||
Request for Comments: 4529 OpenLDAP Foundation
|
||||
Category: Informational June 2006
|
||||
|
||||
|
||||
Requesting Attributes by Object Class in the
|
||||
Lightweight Directory Access Protocol (LDAP)
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This memo provides information for the Internet community. It does
|
||||
not specify an Internet standard of any kind. Distribution of this
|
||||
memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
The Lightweight Directory Access Protocol (LDAP) search operation
|
||||
provides mechanisms for clients to request all user application
|
||||
attributes, all operational attributes, and/or attributes selected by
|
||||
their description. This document extends LDAP to support a mechanism
|
||||
that LDAP clients may use to request the return of all attributes of
|
||||
an object class.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Background and Intended Use .....................................1
|
||||
2. Terminology .....................................................2
|
||||
3. Return of all Attributes of an Object Class .....................2
|
||||
4. Security Considerations .........................................3
|
||||
5. IANA Considerations .............................................3
|
||||
6. References ......................................................4
|
||||
6.1. Normative References .......................................4
|
||||
6.2. Informative References .....................................4
|
||||
|
||||
1. Background and Intended Use
|
||||
|
||||
In the Lightweight Directory Access Protocol (LDAP) [RFC4510], the
|
||||
search operation [RFC4511] supports requesting the return of a set of
|
||||
attributes. This set is determined by a list of attribute
|
||||
descriptions. Two special descriptors are defined to request all
|
||||
user attributes ("*") [RFC4511] and all operational attributes ("+")
|
||||
[RFC3673]. However, there is no convenient mechanism for requesting
|
||||
pre-defined sets of attributes such as the set of attributes used to
|
||||
represent a particular class of object.
|
||||
|
||||
|
||||
|
||||
Zeilenga Informational [Page 1]
|
||||
|
||||
RFC 4529 Requesting Attributes by Object Class June 2006
|
||||
|
||||
|
||||
This document extends LDAP to allow an object class identifier to be
|
||||
specified in attributes lists, such as in Search requests, to request
|
||||
the return of all attributes belonging to an object class. The
|
||||
COMMERCIAL AT ("@", U+0040) character is used to distinguish an
|
||||
object class identifier from an attribute descriptions.
|
||||
|
||||
For example, the attribute list of "@country" is equivalent to the
|
||||
attribute list of 'c', 'searchGuide', 'description', and
|
||||
'objectClass'. This object class is described in [RFC4519].
|
||||
|
||||
This extension is intended primarily to be used where the user is in
|
||||
direct control of the parameters of the LDAP search operation, for
|
||||
instance when entering an LDAP URL [RFC4516] into a web browser, such
|
||||
as <ldap:///dc=example,dc=com?@organization?base>.
|
||||
|
||||
2. Terminology
|
||||
|
||||
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
|
||||
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
|
||||
and "OPTIONAL" are to be interpreted as described in BCP 14
|
||||
[RFC2119].
|
||||
|
||||
DSA stands for Directory System Agent (or server).
|
||||
DSE stands for DSA-specific Entry.
|
||||
|
||||
3. Return of All Attributes of an Object Class
|
||||
|
||||
This extension allows object class identifiers to be provided in the
|
||||
attributes field of the LDAP SearchRequest [RFC4511] or other request
|
||||
values of the AttributeSelection data type (e.g., attributes field in
|
||||
pre/post read controls [ReadEntry]) and/or <attributeSelector>
|
||||
production (e.g., attributes of an LDAP URL [RFC4516]). For each
|
||||
object class identified in the attributes field, the request is to be
|
||||
treated as if each attribute allowed by that class (by "MUST" or
|
||||
"MAY", directly or by "SUP"erior) [RFC4512] were itself listed.
|
||||
|
||||
This extension extends the <attributeSelector> [RFC4511] production
|
||||
as indicated by the following ABNF [RFC4234]:
|
||||
|
||||
attributeSelector =/ objectclassdescription
|
||||
objectclassdescription = ATSIGN oid options
|
||||
ATSIGN = %x40 ; COMMERCIAL AT ("@" U+0040)
|
||||
|
||||
where <oid> and <options> productions are as defined in [RFC4512].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Informational [Page 2]
|
||||
|
||||
RFC 4529 Requesting Attributes by Object Class June 2006
|
||||
|
||||
|
||||
The <oid> component of an <objectclassdescription> production
|
||||
identifies the object class by short name (descr) or object
|
||||
identifier (numericoid). If the value of the <oid> component is
|
||||
unrecognized or does not refer to an object class, the object class
|
||||
description is to be treated as an unrecognized attribute
|
||||
description.
|
||||
|
||||
The <options> production is included in the grammar for extensibility
|
||||
purposes. An object class description with an unrecognized or
|
||||
inappropriate option is to be treated as unrecognized.
|
||||
|
||||
Although object class description options and attribute description
|
||||
options share the same syntax, they are not semantically related.
|
||||
This document does not define any object description option.
|
||||
|
||||
Servers supporting this feature SHOULD publish the object identifier
|
||||
(OID) 1.3.6.1.4.1.4203.1.5.2 as a value of the 'supportedFeatures'
|
||||
[RFC4512] attribute in the root DSE. Clients supporting this feature
|
||||
SHOULD NOT use the feature unless they know that the server supports
|
||||
it.
|
||||
|
||||
4. Security Considerations
|
||||
|
||||
This extension provides a shorthand for requesting all attributes of
|
||||
an object class. Because these attributes could have been listed
|
||||
individually, introduction of this shorthand is not believed to raise
|
||||
additional security considerations.
|
||||
|
||||
Implementors of this LDAP extension should be familiar with security
|
||||
considerations applicable to the LDAP search operation [RFC4511], as
|
||||
well as with general LDAP security considerations [RFC4510].
|
||||
|
||||
5. IANA Considerations
|
||||
|
||||
Registration of the LDAP Protocol Mechanism [RFC4520] defined in this
|
||||
document has been completed.
|
||||
|
||||
Subject: Request for LDAP Protocol Mechanism Registration
|
||||
Object Identifier: 1.3.6.1.4.1.4203.1.5.2
|
||||
Description: OC AD Lists
|
||||
Person & email address to contact for further information:
|
||||
Kurt Zeilenga <kurt@openldap.org>
|
||||
Usage: Feature
|
||||
Specification: RFC 4529
|
||||
Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
|
||||
Comments: none
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Informational [Page 3]
|
||||
|
||||
RFC 4529 Requesting Attributes by Object Class June 2006
|
||||
|
||||
|
||||
This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
|
||||
IANA-assigned private enterprise allocation [PRIVATE], for use in
|
||||
this specification.
|
||||
|
||||
6. References
|
||||
|
||||
6.1. Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
|
||||
Syntax Specifications: ABNF", RFC 4234, October 2005.
|
||||
|
||||
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
|
||||
Protocol (LDAP): Technical Specification Road Map", RFC
|
||||
4510, June 2006.
|
||||
|
||||
[RFC4511] Sermersheim, J., Ed., "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.
|
||||
|
||||
[RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory
|
||||
Access Protocol (LDAP): Uniform Resource Locator", RFC
|
||||
4516, June 2006.
|
||||
|
||||
[X.680] International Telecommunication Union -
|
||||
Telecommunication Standardization Sector, "Abstract
|
||||
Syntax Notation One (ASN.1) - Specification of Basic
|
||||
Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
|
||||
|
||||
6.2. Informative References
|
||||
|
||||
[RFC3673] Zeilenga, K., "Lightweight Directory Access Protocol
|
||||
version 3 (LDAPv3): All Operational Attributes", RFC
|
||||
3673, December 2003.
|
||||
|
||||
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
|
||||
Protocol (LDAP): Schema for User Applications", RFC
|
||||
4519, June 2006.
|
||||
|
||||
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
|
||||
(IANA) Considerations for the Lightweight Directory
|
||||
Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Informational [Page 4]
|
||||
|
||||
RFC 4529 Requesting Attributes by Object Class June 2006
|
||||
|
||||
|
||||
[ReadEntry] Zeilenga, K., "Lightweight Directory Access Protocol
|
||||
(LDAP) Read Entry Controls", RFC 4527, June 2006.
|
||||
|
||||
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
|
||||
http://www.openldap.org/foundation/oid-delegate.txt.
|
||||
|
||||
[PRIVATE] IANA, "Private Enterprise Numbers",
|
||||
http://www.iana.org/assignments/enterprise-numbers.
|
||||
|
||||
Author's Address
|
||||
|
||||
Kurt D. Zeilenga
|
||||
OpenLDAP Foundation
|
||||
|
||||
EMail: Kurt@OpenLDAP.org
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Informational [Page 5]
|
||||
|
||||
RFC 4529 Requesting Attributes by Object Class June 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights 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; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Informational [Page 6]
|
||||
|
||||
451
source/ldap_server/devdocs/rfc4530.txt
Normal file
451
source/ldap_server/devdocs/rfc4530.txt
Normal file
@ -0,0 +1,451 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group K. Zeilenga
|
||||
Request for Comments: 4530 OpenLDAP Foundation
|
||||
Category: Standards Track June 2006
|
||||
|
||||
|
||||
Lightweight Directory Access Protocol (LDAP)
|
||||
entryUUID Operational Attribute
|
||||
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes the LDAP/X.500 'entryUUID' operational
|
||||
attribute and associated matching rules and syntax. The attribute
|
||||
holds a server-assigned Universally Unique Identifier (UUID) for the
|
||||
object. Directory clients may use this attribute to distinguish
|
||||
objects identified by a distinguished name or to locate an object
|
||||
after renaming.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 1]
|
||||
|
||||
RFC 4530 LDAP entryUUID June 2006
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Background and Intended Use .....................................2
|
||||
2. UUID Schema Elements ............................................3
|
||||
2.1. UUID Syntax ................................................3
|
||||
2.2. 'uuidMatch' Matching Rule ..................................3
|
||||
2.3. 'uuidOrderingMatch' Matching Rule ..........................3
|
||||
2.4. 'entryUUID' Attribute ......................................4
|
||||
3. Security Considerations .........................................4
|
||||
4. IANA Considerations .............................................5
|
||||
4.1. Object Identifier Registration .............................5
|
||||
4.2. UUID Syntax Registration ...................................5
|
||||
4.3. 'uuidMatch' Descriptor Registration ........................5
|
||||
4.4. 'uuidOrderingMatch' Descriptor Registration ................5
|
||||
4.5. 'entryUUID' Descriptor Registration ........................6
|
||||
5. Acknowledgements ................................................6
|
||||
6. References ......................................................6
|
||||
6.1. Normative References .......................................6
|
||||
6.2. Informative References .....................................7
|
||||
|
||||
1. Background and Intended Use
|
||||
|
||||
In X.500 Directory Services [X.501], such as those accessible using
|
||||
the Lightweight Directory Access Protocol (LDAP) [RFC4510], an object
|
||||
is identified by its distinguished name (DN). However, DNs are not
|
||||
stable identifiers. That is, a new object may be identified by a DN
|
||||
that previously identified another (now renamed or deleted) object.
|
||||
|
||||
A Universally Unique Identifier (UUID) is "an identifier unique
|
||||
across both space and time, with respect to the space of all UUIDs"
|
||||
[RFC4122]. UUIDs are used in a wide range of systems.
|
||||
|
||||
This document describes the 'entryUUID' operational attribute, which
|
||||
holds the UUID assigned to the object by the server. Clients may use
|
||||
this attribute to distinguish objects identified by a particular
|
||||
distinguished name or to locate a particular object after renaming.
|
||||
|
||||
This document defines the UUID syntax, the 'uuidMatch' and
|
||||
'uuidOrderingMatch' matching rules, and the 'entryUUID' attribute
|
||||
type.
|
||||
|
||||
Schema definitions are provided using LDAP description formats
|
||||
[RFC4512]. Definitions provided here are formatted (line wrapped)
|
||||
for readability.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 2]
|
||||
|
||||
RFC 4530 LDAP entryUUID June 2006
|
||||
|
||||
|
||||
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
|
||||
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
|
||||
and "OPTIONAL" are to be interpreted as described in BCP 14
|
||||
[RFC2119].
|
||||
|
||||
2. UUID Schema Elements
|
||||
|
||||
2.1. UUID Syntax
|
||||
|
||||
A Universally Unique Identifier (UUID) [RFC4122] is a 16-octet (128-
|
||||
bit) value that identifies an object. The ASN.1 [X.680] type UUID is
|
||||
defined to represent UUIDs as follows:
|
||||
|
||||
UUID ::= OCTET STRING (SIZE(16))
|
||||
-- constrained to an UUID [RFC4122]
|
||||
|
||||
In LDAP, UUID values are encoded using the [ASCII] character string
|
||||
representation described in [RFC4122]. For example,
|
||||
"597ae2f6-16a6-1027-98f4-d28b5365dc14".
|
||||
|
||||
The following is an LDAP syntax description suitable for publication
|
||||
in subschema subentries.
|
||||
|
||||
( 1.3.6.1.1.16.1 DESC 'UUID' )
|
||||
|
||||
2.2. 'uuidMatch' Matching Rule
|
||||
|
||||
The 'uuidMatch' matching rule compares an asserted UUID with a stored
|
||||
UUID for equality. Its semantics are the same as the
|
||||
'octetStringMatch' [X.520][RFC4517] matching rule. The rule differs
|
||||
from 'octetStringMatch' in that the assertion value is encoded using
|
||||
the UUID string representation instead of the normal OCTET STRING
|
||||
string representation.
|
||||
|
||||
The following is an LDAP matching rule description suitable for
|
||||
publication in subschema subentries.
|
||||
|
||||
( 1.3.6.1.1.16.2 NAME 'uuidMatch'
|
||||
SYNTAX 1.3.6.1.1.16.1 )
|
||||
|
||||
2.3. 'uuidOrderingMatch' Matching Rule
|
||||
|
||||
The 'uuidOrderingMatch' matching rule compares an asserted UUID with
|
||||
a stored UUID for ordering. Its semantics are the same as the
|
||||
'octetStringOrderingMatch' [X.520][RFC4517] matching rule. The rule
|
||||
differs from 'octetStringOrderingMatch' in that the assertion value
|
||||
is encoded using the UUID string representation instead of the normal
|
||||
OCTET STRING string representation.
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 3]
|
||||
|
||||
RFC 4530 LDAP entryUUID June 2006
|
||||
|
||||
|
||||
The following is an LDAP matching rule description suitable for
|
||||
publication in subschema subentries.
|
||||
|
||||
( 1.3.6.1.1.16.3 NAME 'uuidOrderingMatch'
|
||||
SYNTAX 1.3.6.1.1.16.1 )
|
||||
|
||||
Note that not all UUID variants have a defined ordering; and even
|
||||
where it does, servers are not obligated to assign UUIDs in any
|
||||
particular order. This matching rule is provided for completeness.
|
||||
|
||||
2.4. 'entryUUID' Attribute
|
||||
|
||||
The 'entryUUID' operational attribute provides the Universally Unique
|
||||
Identifier (UUID) assigned to the entry.
|
||||
|
||||
The following is an LDAP attribute type description suitable for
|
||||
publication in subschema subentries.
|
||||
|
||||
( 1.3.6.1.1.16.4 NAME 'entryUUID'
|
||||
DESC 'UUID of the entry'
|
||||
EQUALITY uuidMatch
|
||||
ORDERING uuidOrderingMatch
|
||||
SYNTAX 1.3.6.1.1.16.1
|
||||
SINGLE-VALUE
|
||||
NO-USER-MODIFICATION
|
||||
USAGE directoryOperation )
|
||||
|
||||
Servers SHALL generate and assign a new UUID to each entry upon its
|
||||
addition to the directory and provide that UUID as the value of the
|
||||
'entryUUID' operational attribute. An entry's UUID is immutable.
|
||||
|
||||
UUID are to be generated in accordance with Section 4 of [RFC4122].
|
||||
In particular, servers MUST ensure that each generated UUID is unique
|
||||
in space and time.
|
||||
|
||||
3. Security Considerations
|
||||
|
||||
An entry's relative distinguish name (RDN) is composed from attribute
|
||||
values of the entry, which are commonly descriptive of the object the
|
||||
entry represents. Although deployers are encouraged to use naming
|
||||
attributes whose values are widely disclosable [RFC4514], entries are
|
||||
often named using information that cannot be disclosed to all
|
||||
parties. As UUIDs do not contain any descriptive information of the
|
||||
object they identify, UUIDs may be used to identify a particular
|
||||
entry without disclosure of its contents.
|
||||
|
||||
General UUID security considerations [RFC4122] apply.
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 4]
|
||||
|
||||
RFC 4530 LDAP entryUUID June 2006
|
||||
|
||||
|
||||
General LDAP security considerations [RFC4510] apply.
|
||||
|
||||
4. IANA Considerations
|
||||
|
||||
The IANA has registered the LDAP values [RFC4520] specified in this
|
||||
document.
|
||||
|
||||
4.1. Object Identifier Registration
|
||||
|
||||
Subject: Request for LDAP OID Registration
|
||||
Person & email address to contact for further information:
|
||||
Kurt Zeilenga <kurt@OpenLDAP.org>
|
||||
Specification: RFC 4530
|
||||
Author/Change Controller: IESG
|
||||
Comments:
|
||||
Identifies the UUID schema elements
|
||||
|
||||
4.2. UUID Syntax Registration
|
||||
|
||||
Subject: Request for LDAP Syntax Registration
|
||||
Object Identifier: 1.3.6.1.1.16.1
|
||||
Description: UUID
|
||||
Person & email address to contact for further information:
|
||||
Kurt Zeilenga <kurt@OpenLDAP.org>
|
||||
Specification: RFC 4530
|
||||
Author/Change Controller: IESG
|
||||
Comments:
|
||||
Identifies the UUID syntax
|
||||
|
||||
4.3. 'uuidMatch' Descriptor Registration
|
||||
|
||||
Subject: Request for LDAP Descriptor Registration
|
||||
Descriptor (short name): uuidMatch
|
||||
Object Identifier: 1.3.6.1.1.16.2
|
||||
Person & email address to contact for further information:
|
||||
Kurt Zeilenga <kurt@OpenLDAP.org>
|
||||
Usage: Matching Rule
|
||||
Specification: RFC 4530
|
||||
Author/Change Controller: IESG
|
||||
|
||||
4.4. 'uuidOrderingMatch' Descriptor Registration
|
||||
|
||||
Subject: Request for LDAP Descriptor Registration
|
||||
Descriptor (short name): uuidOrderingMatch
|
||||
Object Identifier: 1.3.6.1.1.16.3
|
||||
Person & email address to contact for further information:
|
||||
Kurt Zeilenga <kurt@OpenLDAP.org>
|
||||
Usage: Matching Rule
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 5]
|
||||
|
||||
RFC 4530 LDAP entryUUID June 2006
|
||||
|
||||
|
||||
Specification: RFC 4530
|
||||
Author/Change Controller: IESG
|
||||
|
||||
4.5. 'entryUUID' Descriptor Registration
|
||||
|
||||
The IANA has registered the LDAP 'entryUUID' descriptor.
|
||||
|
||||
Subject: Request for LDAP Descriptor Registration
|
||||
Descriptor (short name): entryUUID
|
||||
Object Identifier: 1.3.6.1.1.16.4
|
||||
Person & email address to contact for further information:
|
||||
Kurt Zeilenga <kurt@OpenLDAP.org>
|
||||
Usage: Attribute Type
|
||||
Specification: RFC 4530
|
||||
Author/Change Controller: IESG
|
||||
|
||||
5. Acknowledgements
|
||||
|
||||
This document is based upon discussions in the LDAP Update and
|
||||
Duplication Protocols (LDUP) WG. Members of the LDAP Directorate
|
||||
provided review.
|
||||
|
||||
6. References
|
||||
|
||||
6.1. Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
|
||||
Unique IDentifier (UUID) URN Namespace", RFC 4122, July
|
||||
2005.
|
||||
|
||||
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
|
||||
Protocol (LDAP): Technical Specification Road Map", RFC
|
||||
4510, June 2006.
|
||||
|
||||
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
|
||||
(LDAP): Directory Information Models", RFC 4512, June
|
||||
2006.
|
||||
|
||||
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
|
||||
(LDAP): Syntaxes and Matching Rules", RFC 4517, June
|
||||
2006.
|
||||
|
||||
[ASCII] Coded Character Set--7-bit American Standard Code for
|
||||
Information Interchange, ANSI X3.4-1986.
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 6]
|
||||
|
||||
RFC 4530 LDAP entryUUID June 2006
|
||||
|
||||
|
||||
[X.501] International Telecommunication Union -
|
||||
Telecommunication Standardization Sector, "The
|
||||
Directory -- Models," X.501(1993) (also ISO/IEC 9594-
|
||||
2:1994).
|
||||
|
||||
[X.520] International Telecommunication Union -
|
||||
Telecommunication Standardization Sector, "The
|
||||
Directory: Selected Attribute Types", X.520(1993) (also
|
||||
ISO/IEC 9594-6:1994).
|
||||
|
||||
[X.680] International Telecommunication Union -
|
||||
Telecommunication Standardization Sector, "Abstract
|
||||
Syntax Notation One (ASN.1) - Specification of Basic
|
||||
Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
|
||||
|
||||
6.2. Informative References
|
||||
|
||||
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access
|
||||
Protocol (LDAP): String Representation of Distinguished
|
||||
Names", RFC 4514, June 2006.
|
||||
|
||||
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
|
||||
(IANA) Considerations for the Lightweight Directory
|
||||
Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
|
||||
|
||||
Author's Address
|
||||
|
||||
Kurt D. Zeilenga
|
||||
OpenLDAP Foundation
|
||||
|
||||
EMail: Kurt@OpenLDAP.org
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 7]
|
||||
|
||||
RFC 4530 LDAP entryUUID June 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights 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; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 8]
|
||||
|
||||
507
source/ldap_server/devdocs/rfc4531.txt
Normal file
507
source/ldap_server/devdocs/rfc4531.txt
Normal file
@ -0,0 +1,507 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group K. Zeilenga
|
||||
Request for Comments: 4531 OpenLDAP Foundation
|
||||
Category: Experimental June 2006
|
||||
|
||||
|
||||
Lightweight Directory Access Protocol (LDAP)
|
||||
Turn Operation
|
||||
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This memo defines an Experimental Protocol for the Internet
|
||||
community. It does not specify an Internet standard of any kind.
|
||||
Discussion and suggestions for improvement are requested.
|
||||
Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
This specification describes a Lightweight Directory Access Protocol
|
||||
(LDAP) extended operation to reverse (or "turn") the roles of client
|
||||
and server for subsequent protocol exchanges in the session, or to
|
||||
enable each peer to act as both client and server with respect to the
|
||||
other.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Background and Intent of Use ....................................2
|
||||
1.1. Terminology ................................................2
|
||||
2. Turn Operation ..................................................2
|
||||
2.1. Turn Request ...............................................3
|
||||
2.2. Turn Response ..............................................3
|
||||
3. Authentication ..................................................3
|
||||
3.1. Use with TLS and Simple Authentication .....................4
|
||||
3.2. Use with TLS and SASL EXTERNAL .............................4
|
||||
3.3. Use of Mutual Authentication and SASL EXTERNAL .............4
|
||||
4. TLS and SASL Security Layers ....................................5
|
||||
5. Security Considerations .........................................6
|
||||
6. IANA Considerations .............................................6
|
||||
6.1. Object Identifier ..........................................6
|
||||
6.2. LDAP Protocol Mechanism ....................................7
|
||||
7. References ......................................................7
|
||||
7.1. Normative References .......................................7
|
||||
7.2. Informative References .....................................8
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Experimental [Page 1]
|
||||
|
||||
RFC 4531 LDAP Turn Operation June 2006
|
||||
|
||||
|
||||
1. Background and Intent of Use
|
||||
|
||||
The Lightweight Directory Access Protocol (LDAP) [RFC4510][RFC4511]
|
||||
is a client-server protocol that typically operates over reliable
|
||||
octet-stream transports, such as the Transport Control Protocol
|
||||
(TCP). Generally, the client initiates the stream by connecting to
|
||||
the server's listener at some well-known address.
|
||||
|
||||
There are cases where it is desirable for the server to initiate the
|
||||
stream. Although it certainly is possible to write a technical
|
||||
specification detailing how to implement server-initiated LDAP
|
||||
sessions, this would require the design of new authentication and
|
||||
other security mechanisms to support server-initiated LDAP sessions.
|
||||
|
||||
Instead, this document introduces an operation, the Turn operation,
|
||||
which may be used to reverse the client-server roles of the protocol
|
||||
peers. This allows the initiating protocol peer to become the server
|
||||
(after the reversal).
|
||||
|
||||
As an additional feature, the Turn operation may be used to allow
|
||||
both peers to act in both roles. This is useful where both peers are
|
||||
directory servers that desire to request, as LDAP clients, that
|
||||
operations be performed by the other. This may be useful in
|
||||
replicated and/or distributed environments.
|
||||
|
||||
This operation is intended to be used between protocol peers that
|
||||
have established a mutual agreement, by means outside of the
|
||||
protocol, that requires reversal of client-server roles, or allows
|
||||
both peers to act both as client and server.
|
||||
|
||||
1.1. 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 [RFC4511].
|
||||
|
||||
2. Turn Operation
|
||||
|
||||
The Turn operation is defined as an LDAP-Extended Operation
|
||||
[Protocol, Section 4.12] identified by the 1.3.6.1.1.19 OID. The
|
||||
function of the Turn Operation is to request that the client-server
|
||||
roles be reversed, or, optionally, to request that both protocol
|
||||
peers be able to act both as client and server in respect to the
|
||||
other.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Experimental [Page 2]
|
||||
|
||||
RFC 4531 LDAP Turn Operation June 2006
|
||||
|
||||
|
||||
2.1. Turn Request
|
||||
|
||||
The Turn request is an ExtendedRequest where the requestName field
|
||||
contains the 1.3.6.1.1.19 OID and the requestValue field is a BER-
|
||||
encoded turnValue:
|
||||
|
||||
turnValue ::= SEQUENCE {
|
||||
mutual BOOLEAN DEFAULT FALSE,
|
||||
identifier LDAPString
|
||||
}
|
||||
|
||||
A TRUE mutual field value indicates a request to allow both peers to
|
||||
act both as client and server. A FALSE mutual field value indicates
|
||||
a request to reserve the client and server roles.
|
||||
|
||||
The value of the identifier field is a locally defined policy
|
||||
identifier (typically associated with a mutual agreement for which
|
||||
this turn is be executed as part of).
|
||||
|
||||
2.2. Turn Response
|
||||
|
||||
A Turn response is an ExtendedResponse where the responseName and
|
||||
responseValue fields are absent. A resultCode of success is returned
|
||||
if and only if the responder is willing and able to turn the session
|
||||
as requested. Otherwise, a different resultCode is returned.
|
||||
|
||||
3. Authentication
|
||||
|
||||
This extension's authentication model assumes separate authentication
|
||||
of the peers in each of their roles. A separate Bind exchange is
|
||||
expected between the peers in their new roles to establish identities
|
||||
in these roles.
|
||||
|
||||
Upon completion of the Turn, the responding peer in its new client
|
||||
role has an anonymous association at the initiating peer in its new
|
||||
server role. If the turn was mutual, the authentication association
|
||||
of the initiating peer in its pre-existing client role is left intact
|
||||
at the responding peer in its pre-existing server role. If the turn
|
||||
was not mutual, this association is void.
|
||||
|
||||
The responding peer may establish its identity in its client role by
|
||||
requesting and successfully completing a Bind operation.
|
||||
|
||||
The remainder of this section discusses some authentication
|
||||
scenarios. In the protocol exchange illustrations, A refers to the
|
||||
initiating peer (the original client) and B refers to the responding
|
||||
peer (the original server).
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Experimental [Page 3]
|
||||
|
||||
RFC 4531 LDAP Turn Operation June 2006
|
||||
|
||||
|
||||
3.1. Use with TLS and Simple Authentication
|
||||
|
||||
A->B: StartTLS Request
|
||||
B->A: StartTLS(success) Response
|
||||
A->B: Bind(Simple(cn=B,dc=example,dc=net,B's secret)) Request
|
||||
B->A: Bind(success) Response
|
||||
A->B: Turn(TRUE,"XXYYZ") Request
|
||||
B->A: Turn(success) Response
|
||||
B->A: Bind(Simple(cn=A,dc=example,dc=net,A's secret)) Request
|
||||
A->B: Bind(success) Response
|
||||
|
||||
In this scenario, TLS (Transport Layer Security) [RFC4346] is started
|
||||
and the initiating peer (the original client) establishes its
|
||||
identity with the responding peer prior to the Turn using the
|
||||
DN/password mechanism of the Simple method of the Bind operation.
|
||||
After the turn, the responding peer, in its new client role,
|
||||
establishes its identity with the initiating peer in its new server
|
||||
role.
|
||||
|
||||
3.2. Use with TLS and SASL EXTERNAL
|
||||
|
||||
A->B: StartTLS Request
|
||||
B->A: StartTLS(success) Response
|
||||
A->B: Bind(SASL(EXTERNAL)) Request
|
||||
B->A: Bind(success) Response
|
||||
A->B: Turn(TRUE,"XXYYZ") Request
|
||||
B->A: Turn(success) Response
|
||||
B->A: Bind(SASL(EXTERNAL)) Request
|
||||
A->B: Bind(success) Response
|
||||
|
||||
In this scenario, TLS is started (with each peer providing a valid
|
||||
certificate), and the initiating peer (the original client)
|
||||
establishes its identity through the use of the EXTERNAL mechanism of
|
||||
the SASL (Simple Authentication and Security Layer) [RFC4422] method
|
||||
of the Bind operation prior to the Turn. After the turn, the
|
||||
responding peer, in its new client role, establishes its identity
|
||||
with the initiating peer in its new server role.
|
||||
|
||||
3.3. Use of Mutual Authentication and SASL EXTERNAL
|
||||
|
||||
A number of SASL mechanisms, such as GSSAPI [SASL-K5], support mutual
|
||||
authentication. The initiating peer, in its new server role, may use
|
||||
the identity of the responding peer, established by a prior
|
||||
authentication exchange, as its source for "external" identity in
|
||||
subsequent EXTERNAL exchange.
|
||||
|
||||
A->B: Bind(SASL(GSSAPI)) Request
|
||||
<intermediate messages>
|
||||
|
||||
|
||||
|
||||
Zeilenga Experimental [Page 4]
|
||||
|
||||
RFC 4531 LDAP Turn Operation June 2006
|
||||
|
||||
|
||||
B->A: Bind(success) Response
|
||||
A->B: Turn(TRUE,"XXYYZ") Request
|
||||
B->A: Turn(success) Response
|
||||
B->A: Bind(SASL(EXTERNAL)) Request
|
||||
A->B: Bind(success) Response
|
||||
|
||||
In this scenario, a GSSAPI mutual-authentication exchange is
|
||||
completed between the initiating peer (the original client) and the
|
||||
responding server (the original server) prior to the turn. After the
|
||||
turn, the responding peer, in its new client role, requests that the
|
||||
initiating peer utilize an "external" identity to establish its LDAP
|
||||
authorization identity.
|
||||
|
||||
4. TLS and SASL Security Layers
|
||||
|
||||
As described in [RFC4511], LDAP supports both Transport Layer
|
||||
Security (TLS) [RFC4346] and Simple Authentication and Security Layer
|
||||
(SASL) [RFC4422] security frameworks. The following table
|
||||
illustrates the relationship between the LDAP message layer, SASL
|
||||
layer, TLS layer, and transport connection within an LDAP session.
|
||||
|
||||
+----------------------+
|
||||
| LDAP message layer |
|
||||
+----------------------+ > LDAP PDUs
|
||||
+----------------------+ < data
|
||||
| SASL layer |
|
||||
+----------------------+ > SASL-protected data
|
||||
+----------------------+ < data
|
||||
| TLS layer |
|
||||
Application +----------------------+ > TLS-protected data
|
||||
------------+----------------------+ < data
|
||||
Transport | transport connection |
|
||||
+----------------------+
|
||||
|
||||
This extension does not alter this relationship, nor does it remove
|
||||
the general restriction against multiple TLS layers, nor does it
|
||||
remove the general restriction against multiple SASL layers.
|
||||
|
||||
As specified in [RFC4511], the StartTLS operation is used to initiate
|
||||
negotiation of a TLS layer. If a TLS is already installed, the
|
||||
StartTLS operation must fail. Upon establishment of the TLS layer,
|
||||
regardless of which peer issued the request to start TLS, the peer
|
||||
that initiated the LDAP session (the original client) performs the
|
||||
"server identity check", as described in Section 3.1.5 of [RFC4513],
|
||||
treating itself as the "client" and its peer as the "server".
|
||||
|
||||
As specified in [RFC4422], a newly negotiated SASL security layer
|
||||
replaces the installed SASL security layer. Though the client/server
|
||||
|
||||
|
||||
|
||||
Zeilenga Experimental [Page 5]
|
||||
|
||||
RFC 4531 LDAP Turn Operation June 2006
|
||||
|
||||
|
||||
roles in LDAP, and hence SASL, may be reversed in subsequent
|
||||
exchanges, only one SASL security layer may be installed at any
|
||||
instance.
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
Implementors should be aware that the reversing of client/server
|
||||
roles and/or allowing both peers to act as client and server likely
|
||||
introduces security considerations not foreseen by the authors of
|
||||
this document. In particular, the security implications of the
|
||||
design choices made in the authentication and data security models
|
||||
for this extension (discussed in Sections 3 and 4, respectively) are
|
||||
not fully studied. It is hoped that experimentation with this
|
||||
extension will lead to better understanding of the security
|
||||
implications of these models and other aspects of this extension, and
|
||||
that appropriate considerations will be documented in a future
|
||||
document. The following security considerations are apparent at this
|
||||
time.
|
||||
|
||||
Implementors should take special care to process LDAP, SASL, TLS, and
|
||||
other events in the appropriate roles for the peers. Note that while
|
||||
the Turn reverses the client/server roles with LDAP, and in SASL
|
||||
authentication exchanges, it does not reverse the roles within the
|
||||
TLS layer or the transport connection.
|
||||
|
||||
The responding server (the original server) should restrict use of
|
||||
this operation to authorized clients. Client knowledge of a valid
|
||||
identifier should not be the sole factor in determining authorization
|
||||
to turn.
|
||||
|
||||
Where the peers except to establish TLS, TLS should be started prior
|
||||
to the Turn and any request to authenticate via the Bind operation.
|
||||
|
||||
LDAP security considerations [RFC4511][RFC4513] generally apply to
|
||||
this extension.
|
||||
|
||||
6. IANA Considerations
|
||||
|
||||
The following values [RFC4520] have been registered by the IANA.
|
||||
|
||||
6.1. Object Identifier
|
||||
|
||||
The IANA has assigned an LDAP Object Identifier to identify the LDAP
|
||||
Turn Operation, as defined in this document.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Experimental [Page 6]
|
||||
|
||||
RFC 4531 LDAP Turn Operation June 2006
|
||||
|
||||
|
||||
Subject: Request for LDAP Object Identifier Registration
|
||||
Person & email address to contact for further information:
|
||||
Kurt Zeilenga <kurt@OpenLDAP.org>
|
||||
Specification: RFC 4531
|
||||
Author/Change Controller: Author
|
||||
Comments:
|
||||
Identifies the LDAP Turn Operation
|
||||
|
||||
6.2. LDAP Protocol Mechanism
|
||||
|
||||
The IANA has registered the LDAP Protocol Mechanism described in this
|
||||
document.
|
||||
|
||||
Subject: Request for LDAP Protocol Mechanism Registration
|
||||
Object Identifier: 1.3.6.1.1.19
|
||||
Description: LDAP Turn Operation
|
||||
Person & email address to contact for further information:
|
||||
Kurt Zeilenga <kurt@openldap.org>
|
||||
Usage: Extended Operation
|
||||
Specification: RFC 4531
|
||||
Author/Change Controller: Author
|
||||
Comments: none
|
||||
|
||||
7. References
|
||||
|
||||
7.1. Normative References
|
||||
|
||||
[RFC4346] Dierks, T. and, E. Rescorla, "The Transport Layer
|
||||
Security (TLS) Protocol Version 1.1", RFC 4346, April
|
||||
2006.
|
||||
|
||||
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
|
||||
Authentication and Security Layer (SASL)", RFC 4422,
|
||||
June 2006.
|
||||
|
||||
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
|
||||
Protocol (LDAP): Technical Specification Road Map", RFC
|
||||
4510, June 2006.
|
||||
|
||||
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
|
||||
Protocol (LDAP): The Protocol", RFC 4511, June 2006.
|
||||
|
||||
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access
|
||||
Protocol (LDAP): Authentication Methods and Security
|
||||
Mechanisms", RFC 4513, June 2006.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Experimental [Page 7]
|
||||
|
||||
RFC 4531 LDAP Turn Operation June 2006
|
||||
|
||||
|
||||
[X.680] International Telecommunication Union -
|
||||
Telecommunication Standardization Sector, "Abstract
|
||||
Syntax Notation One (ASN.1) - Specification of Basic
|
||||
Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
|
||||
|
||||
[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(2002) (also
|
||||
ISO/IEC 8825-1:2002).
|
||||
|
||||
7.2. Informative References
|
||||
|
||||
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
|
||||
(IANA) Considerations for the Lightweight Directory
|
||||
Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
|
||||
|
||||
[SASL-K5] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") SASL
|
||||
Mechanism", Work in Progress, May 2006.
|
||||
|
||||
Author's Address
|
||||
|
||||
Kurt D. Zeilenga
|
||||
OpenLDAP Foundation
|
||||
|
||||
EMail: Kurt@OpenLDAP.org
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Experimental [Page 8]
|
||||
|
||||
RFC 4531 LDAP Turn Operation June 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights 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; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Experimental [Page 9]
|
||||
|
||||
395
source/ldap_server/devdocs/rfc4532.txt
Normal file
395
source/ldap_server/devdocs/rfc4532.txt
Normal file
@ -0,0 +1,395 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group K. Zeilenga
|
||||
Request for Comments: 4532 OpenLDAP Foundation
|
||||
Category: Standards Track June 2006
|
||||
|
||||
|
||||
Lightweight Directory Access Protocol (LDAP)
|
||||
"Who am I?" Operation
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
This specification provides a mechanism for Lightweight Directory
|
||||
Access Protocol (LDAP) clients to obtain the authorization identity
|
||||
the server has associated with the user or application entity. This
|
||||
mechanism is specified as an LDAP extended operation called the LDAP
|
||||
"Who am I?" operation.
|
||||
|
||||
1. Background and Intent of Use
|
||||
|
||||
This specification describes a Lightweight Directory Access Protocol
|
||||
(LDAP) [RFC4510] operation that clients can use to obtain the primary
|
||||
authorization identity, in its primary form, that the server has
|
||||
associated with the user or application entity. The operation is
|
||||
called the "Who am I?" operation.
|
||||
|
||||
This specification is intended to replace the existing Authorization
|
||||
Identity Controls [RFC3829] mechanism, which uses Bind request and
|
||||
response controls to request and return the authorization identity.
|
||||
Bind controls are not protected by security layers established by the
|
||||
Bind operation that includes them. While it is possible to establish
|
||||
security layers using StartTLS [RFC4511][RFC4513] prior to the Bind
|
||||
operation, it is often desirable to use security layers established
|
||||
by the Bind operation. An extended operation sent after a Bind
|
||||
operation is protected by the security layers established by the Bind
|
||||
operation.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 1]
|
||||
|
||||
RFC 4532 LDAP "Who am I?" Operation June 2006
|
||||
|
||||
|
||||
There are other cases where it is desirable to request the
|
||||
authorization identity that the server associated with the client
|
||||
separately from the Bind operation. For example, the "Who am I?"
|
||||
operation can be augmented with a Proxied Authorization Control
|
||||
[RFC4370] to determine the authorization identity that the server
|
||||
associates with the identity asserted in the Proxied Authorization
|
||||
Control. The "Who am I?" operation can also be used prior to the
|
||||
Bind operation.
|
||||
|
||||
Servers often associate multiple authorization identities with the
|
||||
client, and each authorization identity may be represented by
|
||||
multiple authzId [RFC4513] strings. This operation requests and
|
||||
returns the authzId that the server considers primary. In the
|
||||
specification, the term "the authorization identity" and "the
|
||||
authzId" are generally to be read as "the primary authorization
|
||||
identity" and the "the primary authzId", respectively.
|
||||
|
||||
1.1. Conventions Used in This Document
|
||||
|
||||
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].
|
||||
|
||||
2. The "Who am I?" Operation
|
||||
|
||||
The "Who am I?" operation is defined as an LDAP Extended Operation
|
||||
[RFC4511] identified by the whoamiOID Object Identifier (OID). This
|
||||
section details the syntax of the operation's whoami request and
|
||||
response messages.
|
||||
|
||||
whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
|
||||
|
||||
2.1. The whoami Request
|
||||
|
||||
The whoami request is an ExtendedRequest with a requestName field
|
||||
containing the whoamiOID OID and an absent requestValue field. For
|
||||
example, a whoami request could be encoded as the sequence of octets
|
||||
(in hex):
|
||||
|
||||
30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31
|
||||
2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 2]
|
||||
|
||||
RFC 4532 LDAP "Who am I?" Operation June 2006
|
||||
|
||||
|
||||
2.2. The whoami Response
|
||||
|
||||
The whoami response is an ExtendedResponse where the responseName
|
||||
field is absent and the response field, if present, is empty or an
|
||||
authzId [RFC4513]. For example, a whoami response returning the
|
||||
authzId "u:xxyyz@EXAMPLE.NET" (in response to the example request)
|
||||
would be encoded as the sequence of octets (in hex):
|
||||
|
||||
30 21 02 01 02 78 1c 0a 01 00 04 00 04 00 8b 13
|
||||
75 3a 78 78 79 79 7a 40 45 58 41 4d 50 4c 45 2e
|
||||
4e 45 54
|
||||
|
||||
3. Operational Semantics
|
||||
|
||||
The "Who am I?" operation provides a mechanism, a whoami Request, for
|
||||
the client to request that the server return the authorization
|
||||
identity it currently associates with the client. It also provides a
|
||||
mechanism, a whoami Response, for the server to respond to that
|
||||
request.
|
||||
|
||||
Servers indicate their support for this extended operation by
|
||||
providing a whoamiOID object identifier as a value of the
|
||||
'supportedExtension' attribute type in their root DSE. The server
|
||||
SHOULD advertise this extension only when the client is willing and
|
||||
able to perform this operation.
|
||||
|
||||
If the server is willing and able to provide the authorization
|
||||
identity it associates with the client, the server SHALL return a
|
||||
whoami Response with a success resultCode. If the server is treating
|
||||
the client as an anonymous entity, the response field is present but
|
||||
empty. Otherwise, the server provides the authzId [RFC4513]
|
||||
representing the authorization identity it currently associates with
|
||||
the client in the response field.
|
||||
|
||||
If the server is unwilling or unable to provide the authorization
|
||||
identity it associates with the client, the server SHALL return a
|
||||
whoami Response with an appropriate non-success resultCode (such as
|
||||
operationsError, protocolError, confidentialityRequired,
|
||||
insufficientAccessRights, busy, unavailable, unwillingToPerform, or
|
||||
other) and an absent response field.
|
||||
|
||||
As described in [RFC4511] and [RFC4513], an LDAP session has an
|
||||
"anonymous" association until the client has been successfully
|
||||
authenticated using the Bind operation. Clients MUST NOT invoke the
|
||||
"Who am I?" operation while any Bind operation is in progress,
|
||||
including between two Bind requests made as part of a multi-stage
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 3]
|
||||
|
||||
RFC 4532 LDAP "Who am I?" Operation June 2006
|
||||
|
||||
|
||||
Bind operation. Where a whoami Request is received in violation of
|
||||
this absolute prohibition, the server should return a whoami Response
|
||||
with an operationsError resultCode.
|
||||
|
||||
4. Extending the "Who am I?" Operation with Controls
|
||||
|
||||
Future specifications may extend the "Who am I?" operation using the
|
||||
control mechanism [RFC4511]. When extended by controls, the "Who am
|
||||
I?" operation requests and returns the authorization identity the
|
||||
server associates with the client in a particular context indicated
|
||||
by the controls.
|
||||
|
||||
4.1. Proxied Authorization Control
|
||||
|
||||
The Proxied Authorization Control [RFC4370] is used by clients to
|
||||
request that the operation it is attached to operate under the
|
||||
authorization of an assumed identity. The client provides the
|
||||
identity to assume in the Proxied Authorization request control. If
|
||||
the client is authorized to assume the requested identity, the server
|
||||
executes the operation as if the requested identity had issued the
|
||||
operation.
|
||||
|
||||
As servers often map the asserted authzId to another identity
|
||||
[RFC4513], it is desirable to request that the server provide the
|
||||
authzId it associates with the assumed identity.
|
||||
|
||||
When a Proxied Authorization Control is be attached to the "Who am
|
||||
I?" operation, the operation requests the return of the authzId the
|
||||
server associates with the identity asserted in the Proxied
|
||||
Authorization Control. The authorizationDenied (123) result code is
|
||||
used to indicate that the server does not allow the client to assume
|
||||
the asserted identity.
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
Identities associated with users may be sensitive information. When
|
||||
they are, security layers [RFC4511][RFC4513] should be established to
|
||||
protect this information. This mechanism is specifically designed to
|
||||
allow security layers established by a Bind operation to protect the
|
||||
integrity and/or confidentiality of the authorization identity.
|
||||
|
||||
Servers may place access control or other restrictions upon the use
|
||||
of this operation. As stated in Section 3, the server SHOULD
|
||||
advertise this extension when it is willing and able to perform the
|
||||
operation.
|
||||
|
||||
As with any other extended operations, general LDAP security
|
||||
considerations [RFC4510] apply.
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 4]
|
||||
|
||||
RFC 4532 LDAP "Who am I?" Operation June 2006
|
||||
|
||||
|
||||
6. IANA Considerations
|
||||
|
||||
The OID 1.3.6.1.4.1.4203.1.11.3 is used to identify the LDAP "Who am
|
||||
I?" extended operation. This OID was assigned [ASSIGN] by the
|
||||
OpenLDAP Foundation, under its IANA-assigned private enterprise
|
||||
allocation [PRIVATE], for use in this specification.
|
||||
|
||||
Registration of this protocol mechanism [RFC4520] has been completed
|
||||
by the IANA.
|
||||
|
||||
Subject: Request for LDAP Protocol Mechanism Registration
|
||||
Object Identifier: 1.3.6.1.4.1.4203.1.11.3
|
||||
Description: Who am I?
|
||||
Person & email address to contact for further information:
|
||||
Kurt Zeilenga <kurt@openldap.org>
|
||||
Usage: Extended Operation
|
||||
Specification: RFC 4532
|
||||
Author/Change Controller: IESG
|
||||
Comments: none
|
||||
|
||||
7. Acknowledgement
|
||||
|
||||
This document borrows from prior work in this area, including
|
||||
"Authentication Response Control" [RFC3829] by Rob Weltman, Mark
|
||||
Smith, and Mark Wahl.
|
||||
|
||||
The LDAP "Who am I?" operation takes it's name from the UNIX
|
||||
whoami(1) command. The whoami(1) command displays the effective user
|
||||
ID.
|
||||
|
||||
8. References
|
||||
|
||||
8.1. Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC4370] Weltman, R., "Lightweight Directory Access Protocol (LDAP)
|
||||
Proxied Authorization Control", RFC 4370, February 2006.
|
||||
|
||||
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
|
||||
(LDAP): Technical Specification Road Map", RFC 4510, June
|
||||
2006.
|
||||
|
||||
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
|
||||
Protocol (LDAP): The Protocol", RFC 4511, June 2006.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 5]
|
||||
|
||||
RFC 4532 LDAP "Who am I?" Operation June 2006
|
||||
|
||||
|
||||
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
|
||||
(LDAP): Authentication Methods and Security Mechanisms",
|
||||
RFC 4513, June 2006.
|
||||
|
||||
8.2. Informative References
|
||||
|
||||
[RFC3829] Weltman, R., Smith, M., and M. Wahl, "Lightweight Directory
|
||||
Access Protocol (LDAP) Authorization Identity Request and
|
||||
Response Controls", RFC 3829, July 2004.
|
||||
|
||||
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
|
||||
Considerations for the Lightweight Directory Access
|
||||
Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
|
||||
|
||||
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
|
||||
http://www.openldap.org/foundation/oid-delegate.txt.
|
||||
|
||||
[PRIVATE] IANA, "Private Enterprise Numbers",
|
||||
http://www.iana.org/assignments/enterprise-numbers.
|
||||
|
||||
Author's Address
|
||||
|
||||
Kurt D. Zeilenga
|
||||
OpenLDAP Foundation
|
||||
|
||||
EMail: Kurt@OpenLDAP.org
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 6]
|
||||
|
||||
RFC 4532 LDAP "Who am I?" Operation June 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights 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; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zeilenga Standards Track [Page 7]
|
||||
|
||||
1795
source/ldap_server/devdocs/rfc4533.txt
Normal file
1795
source/ldap_server/devdocs/rfc4533.txt
Normal file
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue
Block a user