upstream/openldap
1
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2026-06-11 01:30:05 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

New LDAP RFCs, including the revised LDAP TS

Browse source
This commit is contained in:
Kurt Zeilenga 2006-06-09 03:19:14 +00:00
parent 1b23abb108
commit 019dcb7589
58 changed files with 23434 additions and 37878 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1937
doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt
View file

File diff suppressed because it is too large Load diff

1179
doc/drafts/draft-ietf-ldapbis-bcp64-xx.txt
View file

File diff suppressed because it is too large Load diff

843
doc/drafts/draft-ietf-ldapbis-dn-xx.txt
View file

@ -1,843 +0,0 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 10 February 2005
Obsoletes: RFC 2253
LDAP: String Representation of Distinguished Names
<draft-ietf-ldapbis-dn-16.txt>
Status of Memo
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document
replacing RFC 2253. Distribution of this memo is unlimited.
Technical discussion of this document will take place on the IETF LDAP
Revision (LDAPBIS) Working Group mailing list
<ietf-ldapbis@openldap.org>. Please send editorial comments directly
to the document editor <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Zeilenga LDAP: Distinguished Names [Page 1]
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
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) [Roadmap],
distinguished names (DNs) are used to unambiguously refer to directory
entries [X.501][Models].
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
implementations with a human user interface would display these
strings directly to the user, but 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 [Protocol][Syntaxes]. 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 a
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 which 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 [Syntaxes].
This document is a integral part of the LDAP technical specification
[Roadmap] which obsoletes the previously defined LDAP technical
Zeilenga LDAP: Distinguished Names [Page 2]
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
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][Models].
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].
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 an 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 which conform to the
grammar defined in Section 3 SHALL be produced by LDAP
implementations.
2.1. Converting the RDNSequence
Zeilenga LDAP: Distinguished Names [Page 3]
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
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.
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)
[Models] and that short name is known to be registered
[REGISTRY][BCP64bis] 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> is defined in [Models].
Implementations are not expected to dynamically update their knowledge
of registered short names. However, implementations SHOULD provide a
mechanism to allow its 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
Zeilenga LDAP: Distinguished Names [Page 4]
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
the X.500 AttributeValue. This form is also used when the syntax of
the AttributeValue does not have a LDAP-specific [Syntaxes, 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 which has a
LDAP-specific string encoding, the value is converted first to a UTF-8
encoded Unicode string according to its syntax specification (see
[Syntaxes, Section 3.3] for examples). If that UTF-8 encoded Unicode
string does not have any of the following characters which 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;
- 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
Zeilenga LDAP: Distinguished Names [Page 5]
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
Augmented BNF [RFC2234] 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 /
%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>, <UTFMB> are defined in [Models].
Each <attributeType>, either a <descr> or a <numericoid>, refers to an
attribute type of an attribute value assertion (AVA). The
<attributeType> is followed by a <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>;
Zeilenga LDAP: Distinguished Names [Page 6]
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
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>.
One or more attribute values assertions, separated by <PLUS>, for a
relative distinguished name.
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.
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)
Implementations MAY recognize other DN string representations (such as
that described in RFC 1779). However, as there is no requirement that
alternative DN string representations to 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 name containing three RDNs, in which the first RDN
is multi-valued:
OU=Sales+CN=J. Smith,DC=example,DC=net
Zeilenga LDAP: Distinguished Names [Page 7]
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
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 which 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.
1.3.6.1.4.1.1466.0=#04024869
Finally, this example shows an RDN whose commonName value consisting
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
could be encoded in printable 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
[Protocol] and other documents comprising the LDAP Technical
Specification [Roadmap].
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:
Zeilenga LDAP: Distinguished Names [Page 8]
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
- 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 which prohibit disclosure of certain
kinds of descriptive information (e.g., email addresses). Hence,
servers implementors are encouraged to support DIT structural rules
and name forms [Models] as these provide a mechanism for
administrators to select appropriate naming attributes for entries.
Administrators are encouraged to use these mechanisms, access
controls, and other administrative controls which may be available to
restrict use of attributes containing sensitive information in naming
of entries. Additionally, use of authentication and data security
services in LDAP [AuthMeth][Protocol] 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 which 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 of the PrintableString choice would have the same
representation <CN=Sam>.
Applications which 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. Acknowledgment
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.
Zeilenga LDAP: Distinguished Names [Page 9]
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
7. Document Editor's Address
Kurt D. Zeilenga
OpenLDAP Foundation
Email: Kurt@OpenLDAP.org
8. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
8.1. Normative References
[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 (also RFC 2119), March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629 (also STD 63), November 2003.
[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/).
[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Zeilenga LDAP: Distinguished Names [Page 10]
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[Schema] Dally, K. (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in
progress.
[REGISTRY] IANA, Object Identifier Descriptors Registry,
<http://www.iana.org/...>.
8.2. Informative References
[ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[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.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.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
[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/>.
Zeilenga LDAP: Distinguished Names [Page 11]
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
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. Presentation of translated DN strings issues 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 which implementors 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 which 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 white space (as demonstrated in Section 4), it is
noted that DN strings may end with white space. Careful readers of
Section 3 will note that 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\ > distinguished the string
representation of the DN comprised 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 white space after the RDN separator character or, if
necessary, after the AVA separator character. It should be noted to
the user that the inserted white space 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 LDAP: Distinguished Names [Page 12]
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
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 white
space is to be removed before the DN string is used in LDAP.
It is not advised to insert white space otherwise as it may not be
obvious to the user which white space is part of the DN string and
which white space 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". Remove
"as an example" language. Added statement (in Section 3) allowing
recognition of additional names but require recognization of those
names in the published table. The table is now published in
Section 3.
- Removed specification of additional requirements for LDAPv2
implementations which also support LDAPv3 (RFC 2253, Section 4) as
LDAPv2 is now Historic.
- Allow 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 are
present. Indicated that null (U+0000) character is to be escaped.
Zeilenga LDAP: Distinguished Names [Page 13]
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
Indicated that equals sign ('=' U+003D) character may be escaped
as '\='.
- Rewrote Section 3 to use ABNF as defined in RFC 2234.
- Updated the Section 3 ABNF. Changes include:
+ allow AttributeType short names of length 1 (e.g., 'L'),
+ use more restrictive <oid> production in AttributeTypes,
+ do not require escaping of equals sign ('=' U+003D) characters,
+ do not require escaping of non-leading number sign ('#' U+0023)
characters,
+ allow space (' ' U+0020) to escaped as '\ ',
+ require 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.
Intellectual Property Rights
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.
Zeilenga LDAP: Distinguished Names [Page 14]
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
Full Copyright
Copyright (C) The Internet Society (2005). 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.
Zeilenga LDAP: Distinguished Names [Page 15]

2857
doc/drafts/draft-ietf-ldapbis-models-xx.txt
View file

File diff suppressed because it is too large Load diff

3709
doc/drafts/draft-ietf-ldapbis-protocol-xx.txt
View file

File diff suppressed because it is too large Load diff

396
doc/drafts/draft-ietf-ldapbis-roadmap-xx.txt
View file

@ -1,396 +0,0 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 10 February 2005
Obsoletes: RFC 2251-2256, 2829-2830, 3377, 3771
Lightweight Directory Access Protocol (LDAP):
Technical Specification Road Map
<draft-ietf-ldapbis-roadmap-07.txt>
Status of this Memo
This document is intended to be published as a Standard Track RFC.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Revision Working Group
mailing list <ietf-ldapbis@openldap.org>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Zeilenga LDAP: TS Road Map [Page 1]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
Abstract
The Lightweight Directory Access Protocol (LDAP) is an Internet
protocol for accessing distributed directory services which act in
accordance with X.500 data and service models. This document provides
a roadmap of the LDAP Technical Specification.
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].
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 [Protocol],
LDAP: Directory Information Models [Models],
LDAP: Authentication Methods and Connection Level Security
Mechanisms [AuthMeth],
LDAP: String Representation of Distinguished Names [LDAPDN],
LDAP: String Representation of Search Filters [Filters],
LDAP: Uniform Resource Locator [LDAPURL],
LDAP: Syntaxes and Matching Rules [Syntaxes],
LDAP: Internationalized String Preparation [LDAPprep], and
LDAP: User Schema [Schema].
The terms "LDAP" and "LDAPv3" are commonly used to informally refer 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-extension(s) is not defined by this document but may be
defined in some future document(s). Extensions are expected to be
truly optional.
IANA (Internet Assigned Numbers Authority) considerations for LDAP
described in BCP 64 [BCP64bis] apply fully to this revision of the
LDAP technical specification.
Zeilenga LDAP: TS Road Map [Page 2]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
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
X.500(1993) series of International Telecommunication Union - Telecom
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, e.g. 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 is 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. Security Considerations
LDAP security considerations are discussed in each document comprising
the technical specification.
4. Relationship to Obsolete Specifications
This technical specification, as defined in Section 1, obsoletes
entirely the previously defined LDAP technical specification [RFC3377]
(which consists of RFC 2251-2256, RFC 2829-2830, RFC 3771, and RFC
3377 itself). The technical specification was significantly
reorganized.
This document replaces RFC 3377 as well as Section 3.3 of RFC 2251.
[Models] replaces portions of RFC 2251, RFC 2252 and RFC 2256.
[Protocol] replaces the majority RFC 2251, portions of RFC 2252, and
all of RFC 3771. [AuthMeth] replaces RFC 2829, RFC 2830, and portions
of RFC 2251. [Syntaxes] replaces the majority of RFC 2252 and
portions of RFC 2256. [Schema] replaces the majority of RFC 2256.
[LDAPDN] replaces RFC 2253. [Filters] replaces RFC 2254. [LDAPURL]
replaces RFC 2255.
[LDAPprep] 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
Zeilenga LDAP: TS Road Map [Page 3]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
replace a number of other documents not listed above. These
relationships are discussed in the documents detailings these portions
of this technical specification.
5. Acknowledgments
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.
6. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
Email: Kurt@OpenLDAP.org
7. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
Zeilenga LDAP: TS Road Map [Page 4]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
work in progress.
[Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
Representation of Search Filters",
draft-ietf-ldapbis-filter-xx.txt, a work in progress.
[LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
draft-ietf-ldapbis-url-xx.txt, a work in progress.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[LDAPprep] Zeilenga, K., "LDAP: Internationalized String
Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work
in progress.
[Schema] Dally, K. (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in
progress.
[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).
7.2. Informative References
None.
Appendix A. Changes to Previous Documents
This appendix outlines changes this document makes relative to the
documents it replaces (in whole or in part).
Zeilenga LDAP: TS Road Map [Page 5]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
Appendix 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.
Appendix 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.
Intellectual Property Rights
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.
Full Copyright
Copyright (C) The Internet Society (2005). 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.
Zeilenga LDAP: TS Road Map [Page 6]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
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.
Zeilenga LDAP: TS Road Map [Page 7]

787
doc/drafts/draft-ietf-ldapbis-strprep-xx.txt
View file

@ -1,787 +0,0 @@
Internet-Draft Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 23 January 2006
LDAP: Internationalized String Preparation
<draft-ietf-ldapbis-strprep-07.txt>
Status of this Memo
This document is intended to be published as a Standard Track RFC.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Revision Working Group
mailing list <ietf-ldapbis@openldap.org>. Please send editorial
comments directly to the editor <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2006). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Zeilenga LDAPprep [Page 1]
Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 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.
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
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 which has a mark property (Mn, Mc,
Me). Appendix A provides a definitive list of combining marks.
1. Introduction
1.1. Background
A Lightweight Directory Access Protocol (LDAP) [Roadmap] matching rule
[Syntaxes] 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 or not.
Zeilenga LDAPprep [Page 2]
Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 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 (amongst other
things) value syntaxes and matching rules for comparing values
commonly used in the Directory. 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 which folded lower case characters
to upper case would yield different different results than an
implementation which used upper case to lower case 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 and 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
Zeilenga LDAPprep [Page 3]
Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
characters insignificant to the matching rule.
Hence, preparation of character strings for X.500 matching 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 a integral part of the LDAP technical specification
[Roadmap] which obsoletes the previously defined LDAP technical
specification [RFC3377] in its entirety.
This document details new LDAP internationalized character string
preparation algorithms used by [Syntaxes] and possible other technical
specifications defining LDAP syntaxes and/or matching rules.
1.5. Relationship to X.500
LDAP is defined [Roadmap] 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.
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
Zeilenga LDAPprep [Page 4]
Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
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 described
expected matching behavior. Implementations are free 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] value 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.
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
Zeilenga LDAPprep [Page 5]
Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
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 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 which, per Section 5.8 of [Stringprep], change display
properties or are deprecated are prohibited. These characters are are
listed in Table C.8 of [RFC3454].
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.
Zeilenga LDAPprep [Page 6]
Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
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).
If the input string contains at least one non-space character, then
the string is modified such that the string starts with exactly one
space character, ends with exactly one SPACE character, and that 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>", results in the output
"<SPACE>foo<SPACE><SPACE>bar<SPACE>".
Otherwise, if the string being prepared is an initial, any, or final
substring, then the output string is exactly one SPACE character, else
the output string is exactly two SPACEs.
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>"
Zeilenga LDAPprep [Page 7]
Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
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
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 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 for International Strings ('stringprep')" [RFC3454]
security considerations generally apply to the algorithms described
here.
4. Acknowledgments
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.
Zeilenga LDAPprep [Page 8]
Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
5. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
Email: Kurt@OpenLDAP.org
6. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ('stringprep')", RFC 3454,
December 2002.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[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).
Zeilenga LDAPprep [Page 9]
Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
6.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.
[Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
Representation of Search Filters",
draft-ietf-ldapbis-filter-xx.txt, a work in progress.
[XMATCH] Zeilenga, K., "Internationalized String Matching Rules
for X.500", draft-zeilenga-ldapbis-strmatch-xx.txt, a
work in progress.
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
Zeilenga LDAPprep [Page 10]
Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
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 absence of substrings matching, the insignificant
space handling for case ignore/exact matching could be
simplified. Specifically, the handling could be as
require all sequences of one or more spaces be replaced
with one space and, if string contains non-space
characters, removal of all 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" but not
"foo<SPACE>bar" nor "foo<SPACE><SPACE>bar";
2) (CN=*\20foobar\20*) would match "foobar", but (CN=*\20*foobar*\20*)
would not;
3) (CN=foo\20*\20bar) would match "foo<SPACE>X<SPACE>bar" but not
"foo<SPACE><SPACE>bar".
Note to readers not familiar with LDAP substrings matching: the LDAP
filter [Filters] assertion (CN=A*B*C) says "match any value (of the
attribute CN) which 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
Zeilenga LDAPprep [Page 11]
Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
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.
The third case illustrates that this simplified space handling causes
another partitioning failure. Though both the initial or final
strings match different portions of "foo<SPACE>X<SPACE>bar" with
neither matching the X portion, they don't match a string consisting
of the two matched portions less the unmatched X portion.
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.
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 which differs only by inclusion
or removal of insignificant characters.
Zeilenga LDAPprep [Page 12]
Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
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
which could be considered insignificant. For instance, the assertion
(CN=\20*\20*\20) does not match "<SPACE><SPACE><SPACE>"
(insignificant spaces present in value) nor " " (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.
Intellectual Property Rights
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.
Full Copyright
Copyright (C) The Internet Society (2006).
Zeilenga LDAPprep [Page 13]
Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 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.
Zeilenga LDAPprep [Page 14]

841
doc/drafts/draft-ietf-ldapbis-url-xx.txt
View file

@ -1,841 +0,0 @@
Network Working Group Mark Smith, Editor
Request for Comments: DRAFT Pearl Crescent, LLC
Obsoletes: RFC 2255 Tim Howes
Expires: 4 July 2005 Opsware, Inc.
4 January 2005
LDAP: Uniform Resource Locator
<draft-ietf-ldapbis-url-09.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she become
aware will be disclosed, in accordance with RFC 3668.
This document is intended to be published as a Standards Track RFC,
replacing RFC 2255. Distribution of this memo is unlimited.
Technical discussion of this document will take place on the IETF
LDAP (v3) Revision (ldapbis) Working Group mailing list
<ietf-ldapbis@openldap.org>. Please send editorial comments directly
to the editor <mcs@pearlcrescent.com>.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2004). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Smith & Howes Intended Category: Standards Track [Page 1]
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
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
Status of this Memo............................................1
Abstract.......................................................2
Table of Contents..............................................2
1. Introduction...................................................2
2. URL Definition.................................................3
2.1. Percent-Encoding............................................5
3. Defaults for Fields of the LDAP URL............................5
4. Examples.......................................................6
5. Security Considerations........................................8
6. IANA Considerations............................................9
7. Normative References...........................................9
8. Informative References.........................................10
9. Acknowledgements...............................................10
10. Authors' Addresses.............................................11
11. Appendix A: Changes Since RFC 2255.............................11
11.1. Technical Changes...........................................11
11.2. Editorial Changes...........................................12
12. Appendix B: Changes Since Previous Document Revision...........14
12.1. Technical Changes...........................................14
12.2. Editorial Changes...........................................14
Intellectual Property Rights...................................14
Full Copyright.................................................15
1. Introduction
LDAP is the Lightweight Directory Access Protocol [Roadmap]. 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 of the parameters of the LDAP search operation
described in [Protocol] can be expressed using the format defined in
this document. Note also that URLs may be used to represent reference
knowledge, including for non-search operations.
Smith & Howes Intended Category: Standards Track [Page 2]
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
This document is a integral part of the LDAP technical specification
[Roadmap] 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
[RFC2234].
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 [RFC2396bis].
; <filter> is from Section 3 of
; [Filters], subject to the
; provisions of the
; "Percent-Encoding" section
; below.
scheme = "ldap"
dn = distinguishedName ; From Section 3 of [LDAPDN],
; 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
; [Protocol], subject to the
; provisions of the
; "Percent-Encoding" section
; below.
scope = "base" / "one" / "sub"
extensions = extension *(COMMA extension)
extension = [EXCLAMATION] extype [EQUALS exvalue]
Smith & Howes Intended Category: Standards Track [Page 3]
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
extype = oid ; From section 1.4 of [Models].
exvalue = LDAPString ; From section 4.1.2 of
; [Protocol], 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 [RFC2396bis].
The <dn> is an LDAP Distinguished Name using the string format
described in [LDAPDN]. 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.
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 [Filters].
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
Smith & Howes Intended Category: Standards Track [Page 4]
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
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 it 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
[LDAPIANA] 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 [RFC2396bis]:
<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 [RFC2396bis] in any of these situations:
The octet is not in the reserved set defined in section 2.2 of
[RFC2396bis] or in the unreserved set defined in section 2.3 of
[RFC2396bis].
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
Smith & Howes Intended Category: Standards Track [Page 5]
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
specify different defaulting rules; for example, section 4.1.10 of
[Protocol] 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 apriori 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.
4. Examples
The following are some example LDAP URLs using 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
Smith & Howes Intended Category: Standards Track [Page 6]
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
"(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" is given below, illustrating
the use of the percent-encoding mechanism on the reserved character
'?'.
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
filters quoting mechanism and 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.
Smith & Howes Intended Category: Standards Track [Page 7]
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
The next example illustrates the interaction between the LDAP string
representation of 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 that are equivalent, assuming that the
defaulting rules specified in section 4 of this document are used:
ldap://ldap.example.net
ldap://ldap.example.net/
ldap://ldap.example.net/?
These three URLs all 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
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
General URL security considerations discussed in [RFC2396bis] 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 using 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
Smith & Howes Intended Category: Standards Track [Page 8]
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
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 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 [AuthMeth] 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, the initiation of a long-lived
search, etc. The security implications of resolving an LDAP URL are
the same as those of resolving an LDAP search query.
6. IANA Considerations
This document has no actions for IANA.
7. Normative References
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a
work in progress.
[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
in progress.
[Filters] Smith, M. and Howes, T., "LDAP: String Representation of
Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in
Smith & Howes Intended Category: Standards Track [Page 9]
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
progress.
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels," RFC 2119, BCP 14, March 1997.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2396bis]
Berners-Lee, T., Fielding, R. and Masinter, L., "Uniform
Resource Identifiers (URI): Generic Syntax",
draft-fielding-uri-rfc2396bis-xx.txt, a work in progress.
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 3629, November 2003.
8. Informative References
[LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. None.
9. 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 is an update to 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 Intended Category: Standards Track [Page 10]
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
10. Authors' Addresses
Mark Smith, Editor
Pearl Crescent, LLC
447 Marlpool Dr.
Saline, MI 48176
USA
+1 734 944-2856
mcs@pearlcrescent.com
Tim Howes
Opsware, Inc.
599 N. Mathilda Ave.
Sunnyvale, CA 94085
USA
+1 408 744-7509
howes@opsware.com
11. Appendix A: Changes Since RFC 2255
11.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 [Models].
Replaced references to [RFC2396] with a reference to [RFC2396bis]
(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 [RFC2396bis] required changes to the ABNF
and text so that productions that are no longer defined by
[RFC2396bis] are not used. For example, <hostport> is not defined by
[RFC2396bis] so it has been replaced with host [COLON port]. Note:
[RFC2396bis] 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 [Protocol]. This allows 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.
Smith & Howes Intended Category: Standards Track [Page 11]
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
Changed the ABNF for <ldapurl> to group the <dn> component with the
preceding <SLASH>.
Changed the <extype> rule to be an <oid> from [Models].
Changed the text about extension types so it references [LDAPIANA].
Reordered rules to more closely follow the order the elements appear
in the URL.
"Bindname Extension": removed due to lack of known implementations.
11.2. Editorial Changes
Changed document title to include "LDAP:" prefix.
IESG Note: removed note about lack of satisfactory mandatory
authentication mechanisms.
"Status of this Memo" section: updated boilerplate to match current
I-D guidelines.
"Abstract" section: separated from introductory material.
"Table of Contents" and "IANA Considerations" 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 [Protocol] 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 [Protocol]." because [Protocol]'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 2234.
Clarified and strengthened the requirements with respect to
Smith & Howes Intended Category: Standards Track [Page 12]
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
processing of URLs that contain implements and not implemented
extensions (the approach now closely matches that specified in
[Protocol] 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 [Protocol].
"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 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 [AuthMeth]. 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 about this being an
update to 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 [Protocol] style throughout the
document. Added references to RFC 2234 and RFC 3629. Updated all
RFC 1738 references to point to the appropriate sections within
[RFC2396bis]. Updated the LDAP references to refer to LDAPBis WG
documents. Removed the reference to the LDAP Attribute Syntaxes
document and added references to the [AuthMeth], [LDAPIANA], and
[Roadmap] documents.
"Informative References" section: added.
Header and "Authors' Addresses" sections: added "editor" next to Mark
Smith's name. Updated affiliation and contact information.
Smith & Howes Intended Category: Standards Track [Page 13]
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
Copyright: updated the year.
Throughout the document: surrounded the names of all ABNF productions
with "<" and ">" where they are used in descriptive text.
12. Appendix B: Changes Since Previous Document Revision
This appendix lists all changes relative to the previously published
revision, draft-ietf-ldapbis-url-08.txt. Note that when appropriate
these changes are also included in Appendix A, but are also included
here for the benefit of the people who have already reviewed
draft-ietf-ldapbis-url-08.txt. This section will be removed before
this document is published as an RFC.
12.1. Technical Changes
Throughout the document: Replaced references to [RFC2396] and
[RFC2732] with references to [RFC2396bis]. This required changes to
the ABNF and text so that productions that are no longer defined by
[RFC2396bis] are not used. For example, <hostport> is not defined by
[RFC2396bis] so it has been replaced with host [COLON port]. Note:
[RFC2396bis] 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).
12.2. Editorial Changes
Throughout the document: Replaced phrases like "Escaping using the %
method" with "Percent-encoding" to be consistent with the terminology
used in [RFC2396bis].
"URL Definition" section: For consistency, replaced all occurrences
of the phrase 'see the "Percent-Encoding" section below' with
'subject to the provisions of the "Percent-Encoding" section below.'
Updated the copyright year to 2005.
Intellectual Property Rights
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
Smith & Howes Intended Category: Standards Track [Page 14]
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
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.
Full Copyright
Copyright (C) The Internet Society (2005). 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.
This Internet Draft expires on 4 July 2005.
Smith & Howes Intended Category: Standards Track [Page 15]

339
doc/drafts/draft-zeilenga-ldap-adlist-xx.txt
View file

@ -1,339 +0,0 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Informational OpenLDAP Foundation
Expires in six months 18 July 2005
Requesting Attributes by Object Class in the
Lightweight Directory Access Protocol
<draft-zeilenga-ldap-adlist-11.txt>
Status of this Memo
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as an Informational document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extensions mailing list
<ldapext@ietf.org>. Please send editorial comments directly to the
author <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Zeilenga Requesting Attributes by Object Class [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
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.
1. Background and Intended Use
In the Lightweight Directory Access Protocol (LDAP) [Roadmap], the
search operation [Protocol] support 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 ("*") [Protocol] 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.
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 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 [Schema].
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 a LDAP URL [LDAPURL] into a web browser. For
example, <ldap:///dc=example,dc=com?@organization?base>.
2. 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].
DSA stands for Directory System Agent (or server).
DSE stands for DSA-specific Entry.
3. Return of all Attributes of an Object Class
Zeilenga Requesting Attributes by Object Class [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
This extension allows object class identifiers is to be provided in
the attributes field of the LDAP SearchRequest [Protocol] 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
[LDAPURL]). 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) [Models] was
itself listed.
This extension extends attributeSelector [Protocol] production as
indicated by the following ABNF [ABNF]:
attributeSelector /= objectclassdescription
objectclassdescription = ATSIGN oid options
ATSIGN = %x40 ; COMMERCIAL AT ("@" U+0040)
where <oid> and <options> productions are as defined in [Models].
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 be
treated an 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 an unrecognized.
While 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'
[Models] attribute in the root DSE. Clients supporting this feature
SHOULD NOT use the feature unless they have knowledge the server
supports it.
3. Security Considerations
This extension provides a shorthand for requesting all attributes of
an object class. As these attributes which 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
Zeilenga Requesting Attributes by Object Class [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
considerations applicable to the LDAP search operation [Protocol], as
well as general LDAP security considerations [Roadmap].
4. IANA Considerations
Registration of the LDAP Protocol Mechanism [BCP64bis] defined in
document is requested.
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 XXXX
Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
Comments: none
This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
IANA-assigned private enterprise allocation [PRIVATE], for use in this
specification.
5. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
Email: Kurt@OpenLDAP.org
6. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", draft-crocker-abnf-rfc2234bis, a
work in progress.
Zeilenga Requesting Attributes by Object Class [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
[LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
draft-ietf-ldapbis-url-xx.txt, a work in progress.
[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., "LDAPv3: All Operational Attributes", RFC
3673, December 2003.
[Schema] Dally, K. (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in
progress.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
[ReadEntry] Zeilenga, K., "LDAP Read Entry Controls",
draft-zeilenga-ldap-readentry-xx.txt, a work in
progress.
[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.
Full Copyright
Copyright (C) The Internet Society (2005).
Zeilenga Requesting Attributes by Object Class [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
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 Rights
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.
Zeilenga Requesting Attributes by Object Class [Page 6]

340
doc/drafts/draft-zeilenga-ldap-assert-xx.txt
View file

@ -1,340 +0,0 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 10 February 2005
The LDAP Assertion Control
<draft-zeilenga-ldap-assert-05.txt>
Status of this Memo
This document is intended to be, after appropriate review and
revision, submitted to the IESG for consideration as a Standard Track
document. Distribution of this memo is unlimited. Technical
discussion of this document will take place on the IETF LDAP
Extensions mailing list <ldapext@ietf.org>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Zeilenga LDAP Assertion Control [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
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" and "test and clear" and other conditional operations.
1. Overview
This document defines the Lightweight Directory Access Protocol (LDAP)
[Roadmap] assertion control. The assertion control allows the client
to specify a condition which must be true for the operation to be
processed normally. Otherwise the operation fails. For instance, the
control can be used with the Modify operation [Protocol] 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 matching the search scope and filter.
The control may also be used with the compare operation. Here it
extends the compare operation to allow a more complex assertion.
2. Terminology
Protocol elements are described using ASN.1 [X.680] 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.2 of [Protocol].
DSA stands for Directory System Agent (or server).
DSE stands for DSA-specific Entry.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
3. The Assertion Control
Zeilenga LDAP Assertion Control [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
The assertion control is an LDAP Control [Protocol] whose controlType
is IANA-ASSIGNED-OID and 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 [Protocol] including Add, Compare, Delete, Modify, ModifyDN
(rename), and Search. It is inappropriate for Abandon, Bind nor
Unbind, and Start TLS operations.
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 (IANA-ASSIGNED-CODE)
resultCode is returned and no further processing is performed.
For Add, Compare, and ModifyDN the target is indicated by the entry
field in the request. For Modify, the target is indicated by the
object field. For Delete, the target is indicated by the DelRequest
type. For the Compare operation and all update operations, the
evaluation of the assertion MUST be performed as an integral part of
the operation. That is, the evaluation of the assertion and the
normal processing of the operation SHALL be done as one atomic action.
For search operation, the target is indicated by the baseObject field
and the evaluation is done after "finding" but before "searching"
[Protocol]. Hence, no entries or continuations references are
returned if the assertion fails.
Servers implementing this technical specification SHOULD publish the
object identifier IANA-ASSIGNED-OID as a value of the
'supportedControl' attribute [Models] 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 so, this information should be
appropriately protected.
As with any general assertion mechanism, the mechanism can be used to
Zeilenga LDAP Assertion Control [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
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.
Security considerations for the base operations [Protocol] extended by
this control, as well as general LDAP security considerations
[Roadmap], generally apply to implementation and use of this
extension.
5. IANA Considerations
5.1. Object Identifier
It is requested that IANA assign upon Standards Action an LDAP Object
Identifier [BCP64bis] to identify the LDAP Assertion Control defined
in this document.
Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
Identifies the LDAP Assertion Control
5.2 LDAP Protocol Mechanism
Registration of this protocol mechanism [BCP64bis] is requested.
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: IANA-ASSIGNED-OID
Description: Assertion Control
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Control
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: none
5.3 LDAP Result Code
Assignment of an LDAP Result Code [BCP64bis] called 'assertionFailed'
is requested.
Zeilenga LDAP Assertion Control [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
Subject: LDAP Result Code Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Result Code Name: assertionFailed
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: none
6. Acknowledgments
The assertion control concept is attributed to Morteza Ansari.
7. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
Email: Kurt@OpenLDAP.org
8. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
8.2. Informative References
Zeilenga LDAP Assertion Control [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
Intellectual Property Rights
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.
Full Copyright
Copyright (C) The Internet Society (2005). 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.
Zeilenga LDAP Assertion Control [Page 6]

445
doc/drafts/draft-zeilenga-ldap-authzid-xx.txt
View file

@ -1,445 +0,0 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 19 November 2004
LDAP "Who am I?" Operation
<draft-zeilenga-ldap-authzid-10.txt>
Status of this Memo
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extensions mailing list
<ldapext@ietf.org>. Please send editorial comments directly to the
author <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright (C) The Internet Society (2004). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Abstract
This specification provides a mechanism for Lightweight Directory
Zeilenga LDAP "Who am I?" [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
Access Protocol (LDAP) clients to obtain the authorization identity
which 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.
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].
1. Background and Intent of Use
This specification describes a Lightweight Directory Access Protocol
(LDAP) [RFC3377] operation which clients can use to obtain the primary
authorization identity in its primary form which 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 [AUTHRESP]
mechanism which uses Bind request and response controls to request and
return the authorization identity. Bind controls are not protected by
the security layers established by the Bind operation which includes
them. While it is possible to establish security layers using Start
TLS [RFC2830] 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.
There are other cases where it is desirable to request the
authorization identity which 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
[PROXYAUTH] to determine the authorization identity which 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 [RFC2829] strings. This operation requests and returns the
authzId the server considers to be 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.
Zeilenga LDAP "Who am I?" [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
2. The "Who am I?" Operation
The "Who am I?" operation is defined as an LDAP Extended Operation
[RFC2251, Section 4.12] 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 the 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
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 [RFC2829]. 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 returns the authorization
identity it currently associates with the client and provides a
mechanism, a whoami Response, for the server to respond to that
request.
Servers indicate their support for this extended operation by
providing whoamiOID object identifier as a value of the
'supportedExtension' attribute type in their root DSE. Server SHOULD
advertise this extension only when the client is willing and able to
perform this operation.
Zeilenga LDAP "Who am I?" [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
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 [RFC2829]
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 [RFC2251] and [RFC2829], 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 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 [RFC2251]. 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 [PROXYAUTH] is used by clients to
request that the operation it is attached to operates 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
[RFC2829], it is desirable to request the server provide the authzId
it associates with the assumed identity.
Zeilenga LDAP "Who am I?" [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
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 TBD result code is used to indicate that the server does
not allow the client to assume the asserted identity. [[Note to RFC
Editor: TBD is to be replaced with the name/code assigned by IANA for
[PROXYAUTH] use.]]
5. Security Considerations
Identities associated with users may be sensitive information. When
so, security layers [RFC2829][RFC2830] 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 [RFC3377] apply.
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 OpenLDAP
Foundation, under its IANA-assigned private enterprise allocation
[PRIVATE], for use in this specification.
Registration of this protocol mechanism [RFC3383] is requested.
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 XXXX
Author/Change Controller: IESG
Comments: none
7. Acknowledgment
This document borrows from prior work in this area including
Zeilenga LDAP "Who am I?" [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
"Authentication Response Control" [AUTHRESP] by Rob Weltman, Mark
Smith and Mark Wahl.
The LDAP "Who am I?" operation takes it name from the UNIX whoami(1)
command. The whoami(1) command displays the effective user id.
8. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
Email: Kurt@OpenLDAP.org
9. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC2829] Wahl, M., H. Alvestrand, and J. Hodges, RL "Bob" Morgan,
"Authentication Methods for LDAP", RFC 2829, June 2000.
[RFC2830] Hodges, J., R. Morgan, and M. Wahl, "Lightweight
Directory Access Protocol (v3): Extension for Transport
Layer Security", RFC 2830, May 2000.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[PROXYAUTH] Weltman, R., "LDAP Proxy Authentication Control",
draft-weltman-ldapv3-proxy-xx.txt, a work in progress.
9.2. Informative References
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
Zeilenga LDAP "Who am I?" [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
(also RFC 3383), September 2002.
[AUTHRESP] Weltman, R., M. Smith and M. Wahl, "LDAP Authorization
Identity Response and Request Controls",
draft-weltman-ldapv3-auth-response-xx.txt, a work in
progress.
[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.
Intellectual Property Rights
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.
Full Copyright
Copyright (C) The Internet Society (2004). 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
Zeilenga LDAP "Who am I?" [Page 7]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
"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.
Zeilenga LDAP "Who am I?" [Page 8]

1403
doc/drafts/draft-zeilenga-ldap-cosine-xx.txt
View file

File diff suppressed because it is too large Load diff

340
doc/drafts/draft-zeilenga-ldap-incr.txt
View file

@ -1,340 +0,0 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Experimental OpenLDAP Foundation
Expires in six months 10 February 2005
LDAP Modify-Increment Extension
<draft-zeilenga-ldap-incr-01.txt>
Status of this Memo
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as an Experimental document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extensions mailing list
<ldapext@ietf.org>. Please send editorial comments directly to the
author <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Zeilenga LDAP Modify-Increment Extension [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
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.
1. Background and Intended Use
The Lightweight Directory Access Protocol [Roadmap] does not currently
provide an operation to increment values of an attribute. A client
must read the values of the attribute, 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 be careful
to construct the modify request so that it fails in this case, and
upon failure, re-read the values and construct a new modify request.
This document extends the LDAP Modify Operation [Protocol] to support
an increment values capability. This feature is intended to be used
with either the LDAP pre-read or post-read control extension
[ReadEntry]. This feature may also be used with the LDAP assertion
control [Assertion] to provide test-and-increment functionality.
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 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 (IANA-
ASSIGNED-TYPE) 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 (IANA-ASSIGNED-TYPE) 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 request, e.g., must
have INTEGER or other increment-able values, and the modification must
provide one and only 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.
Zeilenga LDAP Modify-Increment Extension [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
Servers supporting this feature SHOULD publish the object identifier
(OID) IANA-ASSIGNED-OID as a value of the 'supportedFeatures'
[RFC3674] attribute in the root DSE. Clients supporting this feature
SHOULD NOT use the feature unless they have knowledge the server
supports it.
3. LDIF Support
To represent Modify-Increment requests in LDAP Data Interchange Format
[RFC2849], the ABNF [RFC2234] production <mod-spec> is extended as
follows:
mod-spec /= "increment:" FILL AttributeDescription SEP
attrval-spec "-" SEP
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 [Roadmap], as well as those
specific to the LDAP Modify [Protocol], apply to this Modify-Increment
extension. Beyond these considerations, it is noted that introduction
of this extension should reduce application complexity (by provide one
operation what presently requires multiple operation) and, hence, may
aide in the production of correct and secure implementations.
5. IANA Considerations
Registration of the following values [BCP64bis] is requested.
5.1. Object Identifier
It is requested that IANA assign an LDAP Object Identifier to identify
the LDAP Modify-Increment feature as defined in this document.
Zeilenga LDAP Modify-Increment Extension [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFC XXXX
Author/Change Controller: Author
Comments:
Identifies the LDAP Modify-Increment feature
5.2. LDAP Protocol Mechanism
It is requested that the following LDAP Protocol Mechanism be
registered.
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: IANA-ASSIGNED-OID
Description: Modify-Increment
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Feature
Specification: RFC XXXX
Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
Comments: none
5.3. LDAP Protocol Mechanism
It is requested that IANA assign an LDAP ModifyRequest Operation Type
[BCP64bis] 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 XXXX
Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
Comments: none
6. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
Zeilenga LDAP Modify-Increment Extension [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
7. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
Technical Specification", RFC 2849, June 2000.
[Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674,
December 2003.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
7.2. Informative References
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
[ReadEntry] Zeilenga, K., "LDAP Read Entry Controls",
draft-zeilenga-ldap-readentry-xx.txt, a work in
progress.
[Assertion] Zeilenga, K., "LDAP Assertion Control",
draft-zeilenga-ldap-assert-xx.txt, a work in progress.
[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.
Zeilenga LDAP Modify-Increment Extension [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
Intellectual Property Rights
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.
Full Copyright
Copyright (C) The Internet Society (2005). 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.
Zeilenga LDAP Modify-Increment Extension [Page 6]

452
doc/drafts/draft-zeilenga-ldap-readentry-xx.txt
View file

@ -1,452 +0,0 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 10 February 2005
LDAP Read Entry Controls
<draft-zeilenga-ldap-readentry-04.txt>
1. Status of this Memo
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extensions mailing list
<ldapext@ietf.org>. Please send editorial comments directly to the
author <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Zeilenga LDAP Read Entry Controls [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
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.
1. Background and Intent of Use
This document specifies an extension to the Lightweight Directory
Access Protocol (LDAP) [Roadmap] to allow the client to read the
target entry of an update operation (e.g., Add, Delete, Modify,
ModifyDN). The extension utilizes controls [Protocol] 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' [EntryUUID] and 'modifyTimestamp'
[Models] 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.2 of [Protocol].
DN stands for Distinguished Name.
DSA stands for Directory System Agent (i.e., a directory server).
DSE stands for DSA-specific Entry.
Zeilenga LDAP Read Entry Controls [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
3. Read Entry Controls
3.1. The Pre-Read Controls
The Pre-Read request and response controls are identified by the
IANA-ASSIGNED-OID.1 object identifier. Servers implementing these
controls SHOULD publish IANA-ASSIGNED-OID.1 as a value of the
'supportedControl' [Models] in their root DSE.
The Pre-Read request control is an LDAP Control [Protocol] whose
controlType is IANA-ASSIGNED-OID.1 and whose controlValue is a
BER-encoded AttributeSelection [Protocol], 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 IANA-ASSIGNED-OID.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 target entry
prior to the application of the update. The AttributeSelection
indicates, as discussed in [Protocol][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 response control is provided.
3.2. The Post-Read Controls
The Post-Read request and response controls are identified by the
IANA-ASSIGNED-OID.2 object identifier. Servers implementing these
controls SHOULD publish IANA-ASSIGNED-OID.2 as a value of the
Zeilenga LDAP Read Entry Controls [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
'supportedControl' [Models] in their root DSE.
The Post-Read request control is an LDAP Control [Protocol] whose
controlType is IANA-ASSIGNED-OID.2 and whose controlValue, an OCTET
STRING, contains a BER-encoded AttributeSelection [Protocol], as
extended by [RFC3673]. The criticality may be TRUE or FALSE. This
control is appropriate for the addRequest, modifyRequest, and
modDNRequest LDAP messages.
The corresponding response control is a LDAP Control whose controlType
is IANA-ASSIGNED-OID.2 and 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 target entry
after the application of the update. The AttributeSelection
indicates, as discussed in [Protocol][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 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 [Assertion] and/or the manageDsaIT control
[RFC3296], the semantics of each control included in the combination
apply. 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 both for reading of the information provided in this
control in addition to ensuring the client is authorized to perform
the requested directory update.
Zeilenga LDAP Read Entry Controls [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
Security considerations for the update operations [Protocol] extended
by this control, as well as general LDAP security considerations
[Roadmap], generally apply to implementation and use of this extension
6. IANA Considerations
Registration of the following protocol values [BCP64bis] is requested.
6.1. Object Identifier
It is requested that IANA register an LDAP Object Identifier to
identify LDAP protocol elements defined in this document.
Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
Identifies the LDAP Read Entry Controls
6.2. LDAP Protocol Mechanisms
It is requested that IANA register the LDAP Protocol Mechanism
described in this document.
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: IANA-ASSIGNED-OID.1
Description: LDAP Pre-read Control
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Control
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: none
in 2
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: IANA-ASSIGNED-OID.2
Description: LDAP Post-read Control
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Control
Specification: RFC XXXX
Author/Change Controller: IESG
Zeilenga LDAP Read Entry Controls [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
Comments: none
7. Acknowledgment
The LDAP Pre-Read and Post-Read controls are modeled after similar
capabilities offered in the DAP [X.511].
8. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
[RFC3296] Zeilenga, K., "Named Subordinate References in
Lightweight Directory Access Protocol (LDAP)
Directories", RFC 3296, July 2002.
[RFC3673] Zeilenga, K., "LDAPv3: All Operational Attributes", RFC
3673, December 2003.
[Assertion] Zeilenga, K., "LDAP Assertion Control",
draft-zeilenga-ldap-assert-xx.txt, a work in progress.
[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 -
Zeilenga LDAP Read Entry Controls [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
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).
8.2. Informative References
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
[EntryUUID] Zeilenga, K., "The LDAP EntryUUID Operational
Attribute", draft-zeilenga-ldap-uuid-xx.txt, a work in
progress.
[X.511] International Telecommunication Union -
Telecommunication Standardization Sector, "The
Directory: Abstract Service Definition", X.511(1993)
(also ISO/IEC 9594-3:1993).
10. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
Email: Kurt@OpenLDAP.org
Intellectual Property Rights
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.
Zeilenga LDAP Read Entry Controls [Page 7]
INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
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.
Full Copyright
Copyright (C) The Internet Society (2005). 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.
Zeilenga LDAP Read Entry Controls [Page 8]

340
doc/drafts/draft-zeilenga-ldap-t-f-xx.txt
View file

@ -1,340 +0,0 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 10 February 2005
LDAP Absolute True and False Filters
<draft-zeilenga-ldap-t-f-10.txt>
Status of this Memo
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extensions mailing list
<ldapext@ietf.org>. Please send editorial comments directly to the
author <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Zeilenga LDAP True & False Filters [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
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.
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) which do not necessarily have 'objectClass'
attributes. That is, where "(objectClass=*)" may evaluate to False.
While 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 [Roadmap].
This documents extends LDAPv3 to support absolute True and False
assertions by allowing empty 'and' and 'or' in Search filters
[Protocol] and extends the filter string representation [Filters] to
allow empty filter lists.
It is noted that certain search operations, such as those used to
retrieve subschema information [Models], 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).
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. 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 "(&)".
Zeilenga LDAP True & False Filters [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
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' [RFC3674]
attribute in the root DSE.
Clients supporting this feature SHOULD NOT use the feature unless they
have knowledge 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 [Roadmap].
4. IANA Considerations
Registration of this feature is requested [BCP64bis].
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 XXXX
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. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
6. References
Zeilenga LDAP True & False Filters [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
[Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
Representation of Search Filters",
draft-ietf-ldapbis-filter-xx.txt, a work in progress.
[Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674,
December 2003.
6.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.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
[RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
version 2 (LDAPv2) to Historic Status", RFC 3494, March
2003.
[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).
Zeilenga LDAP True & False Filters [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
[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.
Intellectual Property Rights
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.
Full Copyright
Copyright (C) The Internet Society (2005). 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.
Zeilenga LDAP True & False Filters [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
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.
Zeilenga LDAP True & False Filters [Page 6]

507
doc/drafts/draft-zeilenga-ldap-turn-xx.txt
View file

@ -1,507 +0,0 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Experimental OpenLDAP Foundation
Expires in six months 28 October 2005
LDAP Turn Operation
<draft-zeilenga-ldap-turn-03.txt>
1. Status of this Memo
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor for publication as an
Experimental document. Distribution of this memo is unlimited.
Technical discussion of this document will take place on the IETF LDAP
Extensions mailing list <ldapext@ietf.org>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Abstract
Zeilenga LDAP Turn Op [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
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.
1. Background and Intent of Use
The Lightweight Directory Access Protocol (LDAP) [Roadmap][Protocol]
is a client-server protocol which 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. While 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-servers roles of the protocol
peers. This allows the initiating protocol peer to become 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, 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 which
have established a mutual agreement, by means outside of the protocol,
which 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.2 of [Protocol].
2. Turn Operation
Zeilenga LDAP Turn Op [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
The Turn operation is defined as a LDAP Extended Operation [Protocol,
Section 4.12] identified by the IANA-ASSIGNED-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 to be
able to act both as client and server in respect to the other.
2.1. Turn Request
The Turn request is an ExtendedRequest with the requestName field
containing the IANA-ASSIGNED-OID and a 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.
Zeilenga LDAP Turn Op [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
The responding peer may establish its identity in its client role by
requesting and successfully completing a Bind operation.
The remainder of this section discuss 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).
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
A->B: Bind(Simple(DN/Password)) Request
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) [TLS] is started and
the initiating peer (the original client) establishes its identity
with the responding peer prior to the Turn using the 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 prior 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) [SASL] 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.
Zeilenga LDAP Turn Op [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
3.3. Use of mutual authentication and SASL EXTERNAL
A number of SASL mechanisms, such as GSSAPI [GSSAPI] and DIGEST-MD5
[DIGEST-MD5], support mutual authentication. The initiating peer, it
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>
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 the
responding server (the original server) prior to the turn. After the
turn, the responding peer in its new client role requests the
initiating peer utilize an "external" identity to establish its LDAP
authorization identity.
4. TLS and SASL security layers
As described in [Protocol], LDAP supports both Transport Layer
Security (TLS) [TLS] and Simple Authentication and Security Layer
(SASL) [SASL] 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.
Zeilenga LDAP Turn Op [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
As specified in [Protocol], 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
which initiated the LDAP session (the original client) performs the
"server identity check" as described in Section 3.1.5 of [AuthMeth]
treating itself as the "client" and its peer as the "server".
As specified in [SASL], newly negotiated SASL security layer replace
the installed SASL security layer. Though the client/server 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 the appropriate roles for the peers. It is noted 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 [Protocol][AuthMeth] generally apply to
this extension.
6. IANA Considerations
Zeilenga LDAP Turn Op [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
Registration of the following values [BCP64bis] is requested.
6.1. Object Identifier
It is requested that IANA assign an LDAP Object Identifier to identify
the LDAP Turn Operation 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 XXXX
Author/Change Controller: Author
Comments:
Identifies the LDAP Turn Operation
6.2. LDAP Protocol Mechanism
It is requested that IANA register the LDAP Protocol Mechanism
described in this document.
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: IANA-ASSIGNED-OID
Description: LDAP Turn Operation
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Extended Operation
Specification: RFC XXXX
Author/Change Controller: Author
Comments: none
7. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
Email: Kurt@OpenLDAP.org
8. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
Zeilenga LDAP Turn Op [Page 7]
INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
8.1. Normative References
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
[SASL] Melnikov, A. (Editor), "Simple Authentication and
Security Layer (SASL)",
draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
[TLS] Dierks, T. and, E. Rescorla, "The TLS Protocol Version
1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in
progress.
[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).
8.2. Informative References
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
[GSSAPI] Linn, J., "Generic Security Service
Application Program Interface, Version 2, Update 1", RFC
2743, January 2000.
[DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest
Authentication as a SASL Mechanism",
draft-ietf-sasl-rfc2831bis-xx.txt, a work in progress.
Zeilenga LDAP Turn Op [Page 8]
INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
Intellectual Property Rights
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.
Full Copyright
Copyright (C) The Internet Society (2005).
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.
Zeilenga LDAP Turn Op [Page 9]

451
doc/drafts/draft-zeilenga-ldap-uuid-xx.txt
View file

@ -1,451 +0,0 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 18 July 2005
The LDAP entryUUID operational attribute
<draft-zeilenga-ldap-uuid-06.txt>
Status of this Memo
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as an Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extensions mailing list
<ldapext@ietf.org>. Please send editorial comments directly to the
author <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Abstract
Zeilenga draft-zeilenga-ldap-uuid-06 [Page 1]
INTERNET-DRAFT LDAP entryUUID 18 July 2005
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.
1. Background and Intended Use
In X.500 Directory Services [X.501], such as those accessible using
the Lightweight Directory Access Protocol (LDAP) [Roadmap], 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
which 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"
[UUIDURN]. 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
[Models]. Definitions provided here are formatted (line wrapped) for
readability.
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. UUID Schema Elements
2.1 UUID Syntax
A Universally Unique Identifier (UUID) [UUIDURN] is a 16-octet
(128-bit) value which 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 [UUIDURN]
Zeilenga draft-zeilenga-ldap-uuid-06 [Page 2]
INTERNET-DRAFT LDAP entryUUID 18 July 2005
In LDAP, UUID values are encoded using the [ASCII] character string
representation described in [UUIDURN]. For example,
"597ae2f6-16a6-1027-98f4-d28b5365dc14".
The following is a LDAP syntax description suitable for publication in
subschema subentries.
( IANA-ASSIGNED-OID.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 same as the 'octetStringMatch'
[X.520][Syntaxes] 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 a LDAP matching rule description suitable for
publication in subschema subentries.
( IANA-ASSIGNED-OID.2 NAME 'uuidMatch'
SYNTAX IANA-ASSIGNED-OID.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][Syntaxes] 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.
The following is a LDAP matching rule description suitable for
publication in subschema subentries.
( IANA-ASSIGNED-OID.3 NAME 'uuidOrderingMatch'
SYNTAX IANA-ASSIGNED-OID.1 )
It is noted that not all UUID variants have a defined ordering and,
even where so, servers are not obligated to assign UUIDs in any
particular order. This matching rule is provided for completeness.
2.4. 'entryUUID' attribute
Zeilenga draft-zeilenga-ldap-uuid-06 [Page 3]
INTERNET-DRAFT LDAP entryUUID 18 July 2005
The 'entryUUID' operational attribute provides the Universally Unique
Identifier (UUID) assigned to the entry.
The following is a LDAP attribute type description suitable for
publication in subschema subentries.
( IANA-ASSIGNED-OID.4 NAME 'entryUUID'
DESC 'UUID of the entry'
EQUALITY uuidMatch
ORDERING uuidOrderingMatch
SYNTAX IANA-ASSIGNED-OID.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 [UUIDURN].
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, values which are commonly descriptive of the
object the entry represents. While deployers are encouraged to use
naming attributes whose values are widely disclosable [LDAPDN],
entries are often named using information which 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 [UUIDURN] apply.
General LDAP security considerations [RFC3377] apply.
4. IANA Considerations
It is requested that IANA register upon Standards Action the LDAP
values specified in this document.
4.1. Object Identifier Registration
Zeilenga draft-zeilenga-ldap-uuid-06 [Page 4]
INTERNET-DRAFT LDAP entryUUID 18 July 2005
Subject: Request for LDAP OID Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
Identifies the UUID schema elements
4.2. UUID Syntax Registration
Subject: Request for LDAP Syntax Registration
Object Identifier: IANA-ASSIGNED-OID.1
Description: UUID
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFC XXXX
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: IANA-ASSIGNED-OID.2
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: Matching Rule
Specification: RFC XXXX
Author/Change Controller: IESG
4.3. 'uuidOrderingMatch' Descriptor Registration
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): uuidOrderingMatch
Object Identifier: IANA-ASSIGNED-OID.3
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: Matching Rule
Specification: RFC XXXX
Author/Change Controller: IESG
5.4. 'entryUUID' Descriptor Registration
Zeilenga draft-zeilenga-ldap-uuid-06 [Page 5]
INTERNET-DRAFT LDAP entryUUID 18 July 2005
It is requested that IANA register upon Standards Action the LDAP
'entryUUID' descriptor.
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): entryUUID
Object Identifier: IANA-ASSIGNED-OID.4
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: Attribute Type
Specification: RFC XXXX
Author/Change Controller: IESG
6. Acknowledgments
This document is based upon discussions in the LDAP Update and
Duplication Protocols (LDUP) WG. Members of the LDAP Directorate
provided review.
7. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
Email: Kurt@OpenLDAP.org
8. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[UUIDURN] Leach, P, M. Mealling, R. Salz, "A UUID URN Namespace",
a work in progress.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Zeilenga draft-zeilenga-ldap-uuid-06 [Page 6]
INTERNET-DRAFT LDAP entryUUID 18 July 2005
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[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).
8.2. Informative References
[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
work in progress.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
Intellectual Property Rights
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
Zeilenga draft-zeilenga-ldap-uuid-06 [Page 7]
INTERNET-DRAFT LDAP entryUUID 18 July 2005
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.
Full Copyright
Copyright (C) The Internet Society (2005).
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.
Zeilenga draft-zeilenga-ldap-uuid-06 [Page 8]

1403
doc/drafts/draft-zeilenga-ldap-x509-xx.txt
View file

File diff suppressed because it is too large Load diff

1792
doc/drafts/draft-zeilenga-ldup-sync-xx.txt
View file

File diff suppressed because it is too large Load diff

36
doc/rfc/INDEX
View file

@ -1,19 +1,11 @@
This is an index of RFC contained in this directory:
rfc1274.txt COSINE and Internet X.500 Schema (PS)
rfc2079.txt X.500 Attribute Type and an Object Class to Hold URIs (PS)
rfc2247.txt Using Domains in LDAP DNs (PS)
rfc2251.txt LDAPv3 Protocol (PS)
rfc2252.txt LDAPv3 Attribute Types (PS)
rfc2253.txt LDAPv3 Disinguished Name (PS)
rfc2254.txt LDAPv3 Search Filters (PS)
rfc2255.txt LDAPv3 URL Format (PS)
rfc2256.txt X.500(96) Schema for LDAPv3 (PS)
rfc2293.txt Tables and Subtrees in the X.500 Directory (PS)
rfc2294.txt O/R Address hierarchy in the X.500 DIT (PS)
rfc2307.txt LDAP Network Information Services Schema (E)
rfc2377.txt LDAP Naming Plan (I)
rfc2587.txt Internet X.509 PKI LDAPv2 Schema (PS)
rfc2589.txt LDAPv3: Dynamic Directory Services Extensions (PS)
rfc2649.txt LDAPv3 Operational Signatures (E)
rfc2696.txt LDAP Simple Paged Result Control (I)
@ -30,19 +22,15 @@ rfc3062.txt LDAP Password Modify Extended Operation (PS)
rfc3088.txt OpenLDAP Root Service (E)
rfc3112.txt LDAP Authentication Password Schema (I)
rfc3296.txt Named Subordinate References in LDAP (PS)
rfc3377.txt LDAP(v3): Technical Specification (PS)
rfc3383.txt IANA Considerations for LDAP (BCP)
rfc3663.txt Domain Administrative Data in LDAP (E)
rfc3671.txt Collective Attributes in LDAP (PS)
rfc3672.txt Subentries in LDAP (PS)
rfc3673.txt LDAPv3: All Operational Attributes (PS)
rfc3674.txt Feature Discovery in LDAP (PS)
rfc3687.txt LDAP Component Matching Rules (PS)
rfc3698.txt LDAP: Additional Matching Rules (PS)
rfc3703.txt LDAP: Schema for Policy Core (PS)
rfc3712.txt LDAP: Schema for Printer Services (I)
rfc3727.txt ASN.1 Module for LDAP Component Matching Rules (PS)
rfc3771.txt LDAP: Intermediate Response Message (PS)
rfc3829.txt LDAP Authorization Identity Controls (I)
rfc3866.txt Language Tag and Ranges in LDAP (PS)
rfc3876.txt Returning Matched Values with LDAP (PS)
@ -52,6 +40,30 @@ rfc4013.txt SASLprep (PS)
rfc4370.txt LDAP Proxied Authorization Control (PS)
rfc4373.txt LBURP (I)
rfc4404.txt LDAP Schema for UDDI (I)
rfc4510.txt LDAP Technical Specification Roadmap (PS)
rfc4511.txt LDAP: The Protocol (PS)
rfc4512.txt LDAP: Directory Information Models (PS)
rfc4513.txt LDAP: Authentication Methods and Security Mechanisms (PS)
rfc4514.txt LDAP: DN (PS)
rfc4515.txt LDAP: Search Filters (PS)
rfc4516.txt LDAP: URL (PS)
rfc4517.txt LDAP: Syntaxes and Matching Rules (PS)
rfc4518.txt LDAP: Internationalized String Preparation (PS)
rfc4519.txt LDAP: User Applications Schema (PS)
rfc4520.txt IANA Considerations for LDAP (BCP)
rfc4521.txt Considerations for LDAP Extensions (BCP)
rfc4522.txt LDAP: Binary Encoding Option (PS)
rfc4523.txt LDAP: X.509 Certificate Schema (PS)
rfc4524.txt LDAP: COSINE Schema (PS)
rfc4525.txt LDAP: Modify-Increment Extension (I)
rfc4526.txt LDAP: Absolute True and False Filters (PS)
rfc4527.txt LDAP: Read Entry Controls (PS)
rfc4528.txt LDAP: Assertion Control (PS)
rfc4529.txt LDAP: Requesting Attributes by Object Class
rfc4530.txt LDAP: entryUUID (PS)
rfc4531.txt LDAP Turn Operation (E)
rfc4532.txt LDAP Who am I? Operation (PS)
rfc4533.txt LDAP Content Sync Operation (E)
Legend:
STD Standard

3363
doc/rfc/rfc1274.txt
View file

File diff suppressed because it is too large Load diff

2803
doc/rfc/rfc2251.txt
View file

File diff suppressed because it is too large Load diff

1795
doc/rfc/rfc2252.txt
View file

File diff suppressed because it is too large Load diff

563
doc/rfc/rfc2253.txt
View file

@ -1,563 +0,0 @@
Network Working Group M. Wahl
Request for Comments: 2253 Critical Angle Inc.
Obsoletes: 1779 S. Kille
Category: Standards Track Isode Ltd.
T. Howes
Netscape Communications Corp.
December 1997
Lightweight Directory Access Protocol (v3):
UTF-8 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 (1997). All Rights Reserved.
IESG Note
This document describes a directory access protocol that provides
both read and update access. Update access requires secure
authentication, but this document does not mandate implementation of
any satisfactory authentication mechanisms.
In accordance with RFC 2026, section 4.4.1, this specification is
being approved by IESG as a Proposed Standard despite this
limitation, for the following reasons:
a. to encourage implementation and interoperability testing of
these protocols (with or without update access) before they
are deployed, and
b. to encourage deployment and use of these protocols in read-only
applications. (e.g. applications where LDAPv3 is used as
a query language for directories which are updated by some
secure mechanism other than LDAP), and
c. to avoid delaying the advancement and deployment of other Internet
standards-track protocols which require the ability to query, but
not update, LDAPv3 directory servers.
Wahl, et. al. Proposed Standard [Page 1]
RFC 2253 LADPv3 Distinguished Names December 1997
Readers are hereby warned that until mandatory authentication
mechanisms are standardized, clients and servers written according to
this specification which make use of update functionality are
UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
Implementors are hereby discouraged from deploying LDAPv3 clients or
servers which implement the update functionality, until a Proposed
Standard for mandatory authentication in LDAPv3 has been approved and
published as an RFC.
Abstract
The X.500 Directory uses distinguished names as the primary keys to
entries in the directory. Distinguished Names are encoded in ASN.1
in the X.500 Directory protocols. In the Lightweight Directory
Access Protocol, a string representation of distinguished names is
transferred. This specification defines the string format for
representing names, which is designed to give a clean representation
of commonly used distinguished names, while being able to represent
any distinguished name.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [6].
1. Background
This specification assumes familiarity with X.500 [1], and the
concept of Distinguished Name. 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 clients with a human user interface
would display these strings directly to the user, but would most
likely be performing translations (such as expressing attribute type
names in one of the local national languages).
2. Converting DistinguishedName from ASN.1 to a String
In X.501 [2] the ASN.1 structure of distinguished name is defined as:
DistinguishedName ::= RDNSequence
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
Wahl, et. al. Proposed Standard [Page 2]
RFC 2253 LADPv3 Distinguished Names December 1997
RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue }
The following sections define the algorithm for converting from an
ASN.1 structured representation to a UTF-8 string representation.
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 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 character (',' ASCII 44).
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 2.3), in any order.
Where there is a multi-valued RDN, the outputs from adjoining
AttributeTypeAndValues are separated by a plus ('+' ASCII 43)
character.
2.3. Converting AttributeTypeAndValue
The AttributeTypeAndValue is encoded as the string representation of
the AttributeType, followed by an equals character ('=' ASCII 61),
followed by the string representation of the AttributeValue. The
encoding of the AttributeValue is given in section 2.4.
If the AttributeType is in a published table of attribute types
associated with LDAP [4], then the type name string from that table
is used, otherwise it is encoded as the dotted-decimal encoding of
the AttributeType's OBJECT IDENTIFIER. The dotted-decimal notation is
described in [3]. As an example, strings for a few of the attribute
types frequently seen in RDNs include:
Wahl, et. al. Proposed Standard [Page 3]
RFC 2253 LADPv3 Distinguished Names December 1997
String X.500 AttributeType
------------------------------
CN commonName
L localityName
ST stateOrProvinceName
O organizationName
OU organizationalUnitName
C countryName
STREET streetAddress
DC domainComponent
UID userid
2.4. Converting an AttributeValue from ASN.1 to a String
If the AttributeValue is of a type which does not have a string
representation defined for it, then it is simply encoded as an
octothorpe character ('#' ASCII 35) followed by the hexadecimal
representation of each of the bytes of the BER encoding of the X.500
AttributeValue. This form SHOULD be used if the AttributeType is of
the dotted-decimal form.
Otherwise, if the AttributeValue is of a type which has a string
representation, the value is converted first to a UTF-8 string
according to its syntax specification (see for example section 6 of
[4]).
If the UTF-8 string does not have any of the following characters
which need escaping, then that string can be used as the string
representation of the value.
o a space or "#" character occurring at the beginning of the
string
o a space character occurring at the end of the string
o one of the characters ",", "+", """, "\", "<", ">" or ";"
Implementations MAY escape other characters.
If a character to be escaped is one of the list shown above, then it
is prefixed by a backslash ('\' ASCII 92).
Otherwise the character to be escaped is replaced by a backslash and
two hex digits, which form a single byte in the code of the
character.
Examples of the escaping mechanism are shown in section 5.
Wahl, et. al. Proposed Standard [Page 4]
RFC 2253 LADPv3 Distinguished Names December 1997
3. Parsing a String back to a Distinguished Name
The structure of the string is specified in a BNF grammar, based on
the grammar defined in RFC 822 [5]. Server implementations parsing a
DN string generated by an LDAPv2 client MUST also accept (and ignore)
the variants given in section 4 of this document.
distinguishedName = [name] ; may be empty string
name = name-component *("," name-component)
name-component = attributeTypeAndValue *("+" attributeTypeAndValue)
attributeTypeAndValue = attributeType "=" attributeValue
attributeType = (ALPHA 1*keychar) / oid
keychar = ALPHA / DIGIT / "-"
oid = 1*DIGIT *("." 1*DIGIT)
attributeValue = string
string = *( stringchar / pair )
/ "#" hexstring
/ QUOTATION *( quotechar / pair ) QUOTATION ; only from v2
quotechar = <any character except "\" or QUOTATION >
special = "," / "=" / "+" / "<" / ">" / "#" / ";"
pair = "\" ( special / "\" / QUOTATION / hexpair )
stringchar = <any character except one of special, "\" or QUOTATION >
hexstring = 1*hexpair
hexpair = hexchar hexchar
hexchar = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
/ "a" / "b" / "c" / "d" / "e" / "f"
ALPHA = <any ASCII alphabetic character>
; (decimal 65-90 and 97-122)
DIGIT = <any ASCII decimal digit> ; (decimal 48-57)
QUOTATION = <the ASCII double quotation mark character '"' decimal 34>
Wahl, et. al. Proposed Standard [Page 5]
RFC 2253 LADPv3 Distinguished Names December 1997
4. Relationship with RFC 1779 and LDAPv2
The syntax given in this document is more restrictive than the syntax
in RFC 1779. Implementations parsing a string generated by an LDAPv2
client MUST accept the syntax of RFC 1779. Implementations MUST NOT,
however, generate any of the RFC 1779 encodings which are not
described above in section 2.
Implementations MUST allow a semicolon character to be used instead
of a comma to separate RDNs in a distinguished name, and MUST also
allow whitespace characters to be present on either side of the comma
or semicolon. The whitespace characters are ignored, and the
semicolon replaced with a comma.
Implementations MUST allow an oid in the attribute type to be
prefixed by one of the character strings "oid." or "OID.".
Implementations MUST allow for space (' ' ASCII 32) characters to be
present between name-component and ',', between attributeTypeAndValue
and '+', between attributeType and '=', and between '=' and
attributeValue. These space characters are ignored when parsing.
Implementations MUST allow a value to be surrounded by quote ('"'
ASCII 34) characters, which are not part of the value. Inside the
quoted value, the following characters can occur without any
escaping:
",", "=", "+", "<", ">", "#" and ";"
5. 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):
CN=Steve Kille,O=Isode Limited,C=GB
Here is an example name containing three RDNs, in which the first RDN
is multi-valued:
OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
This example shows the method of quoting of a comma in an
organization name:
CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
Wahl, et. al. Proposed Standard [Page 6]
RFC 2253 LADPv3 Distinguished Names December 1997
An example name in which a value contains a carriage return
character:
CN=Before\0DAfter,O=Test,C=GB
An example name in which an RDN was of an unrecognized type. The
value is the BER encoding of an OCTET STRING containing two bytes
0x48 and 0x69.
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
Finally, an example of an RDN surname value consisting of 5 letters:
Unicode Letter Description 10646 code UTF-8 Quoted
=============================== ========== ====== =======
LATIN CAPITAL LETTER L U0000004C 0x4C L
LATIN SMALL LETTER U U00000075 0x75 u
LATIN SMALL LETTER C WITH CARON U0000010D 0xC48D \C4\8D
LATIN SMALL LETTER I U00000069 0x69 i
LATIN SMALL LETTER C WITH ACUTE U00000107 0xC487 \C4\87
Could be written in printable ASCII (useful for debugging purposes):
SN=Lu\C4\8Di\C4\87
6. References
[1] The Directory -- overview of concepts, models and services.
ITU-T Rec. X.500(1993).
[2] The Directory -- Models. ITU-T Rec. X.501(1993).
[3] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997.
[5] Crocker, D., "Standard of the Format of ARPA-Internet Text
Messages", STD 11, RFC 822, August 1982.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119.
Wahl, et. al. Proposed Standard [Page 7]
RFC 2253 LADPv3 Distinguished Names December 1997
7. Security Considerations
7.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)
Most countries have privacy laws regarding the publication of
information about people.
7.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 or DER form. An example of a situation which 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 of the PrintableString choice would have the same
representation CN=Sam.
Applications which 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 octothorpe ('#')
as described in the first paragraph of section 2.4.
8. Authors' Addresses
Mark Wahl
Critical Angle Inc.
4815 W. Braker Lane #502-385
Austin, TX 78759
USA
EMail: M.Wahl@critical-angle.com
Wahl, et. al. Proposed Standard [Page 8]
RFC 2253 LADPv3 Distinguished Names December 1997
Steve Kille
Isode Ltd.
The Dome
The Square
Richmond, Surrey
TW9 1DT
England
Phone: +44-181-332-9091
EMail: S.Kille@ISODE.COM
Tim Howes
Netscape Communications Corp.
501 E. Middlefield Rd, MS MV068
Mountain View, CA 94043
USA
Phone: +1 650 937-3419
EMail: howes@netscape.com
Wahl, et. al. Proposed Standard [Page 9]
RFC 2253 LADPv3 Distinguished Names December 1997
9. Full Copyright Statement
Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Wahl, et. al. Proposed Standard [Page 10]

451
doc/rfc/rfc2254.txt
View file

@ -1,451 +0,0 @@
Network Working Group T. Howes
Request for Comments: 2254 Netscape Communications Corp.
Category: Standards Track December 1997
The String Representation of LDAP Search Filters
1. 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 (1997). All Rights Reserved.
IESG Note
This document describes a directory access protocol that provides
both read and update access. Update access requires secure
authentication, but this document does not mandate implementation of
any satisfactory authentication mechanisms.
In accordance with RFC 2026, section 4.4.1, this specification is
being approved by IESG as a Proposed Standard despite this
limitation, for the following reasons:
a. to encourage implementation and interoperability testing of
these protocols (with or without update access) before they
are deployed, and
b. to encourage deployment and use of these protocols in read-only
applications. (e.g. applications where LDAPv3 is used as
a query language for directories which are updated by some
secure mechanism other than LDAP), and
c. to avoid delaying the advancement and deployment of other Internet
standards-track protocols which require the ability to query, but
not update, LDAPv3 directory servers.
Howes Standards Track [Page 1]
RFC 2254 String Representation of LDAP December 1997
Readers are hereby warned that until mandatory authentication
mechanisms are standardized, clients and servers written according to
this specification which make use of update functionality are
UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
Implementors are hereby discouraged from deploying LDAPv3 clients or
servers which implement the update functionality, until a Proposed
Standard for mandatory authentication in LDAPv3 has been approved and
published as an RFC.
2. Abstract
The Lightweight Directory Access Protocol (LDAP) [1] 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. This
document defines a human-readable string format for representing LDAP
search filters.
This document replaces RFC 1960, extending the string LDAP filter
definition to include support for LDAP version 3 extended match
filters, and including support for representing the full range of
possible LDAP search filters.
Howes Standards Track [Page 2]
RFC 2254 String Representation of LDAP December 1997
3. LDAP Search Filter Definition
An LDAPv3 search filter is defined in Section 4.5.1 of [1] as
follows:
Filter ::= CHOICE {
and [0] SET OF Filter,
or [1] SET OF 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,
SEQUENCE OF CHOICE {
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString
}
}
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
attributeValue AttributeValue
}
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleID OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE
}
AttributeDescription ::= LDAPString
AttributeValue ::= OCTET STRING
MatchingRuleID ::= LDAPString
AssertionValue ::= OCTET STRING
LDAPString ::= OCTET STRING
Howes Standards Track [Page 3]
RFC 2254 String Representation of LDAP December 1997
where the LDAPString above is limited to the UTF-8 encoding of the
ISO 10646 character set [4]. The AttributeDescription is a string
representation of the attribute description and is defined in [1].
The AttributeValue and AssertionValue OCTET STRING have the form
defined in [2]. The Filter is encoded for transmission over a
network using the Basic Encoding Rules defined in [3], with
simplifications described in [1].
4. String Search Filter Definition
The string representation of an LDAP search filter is defined by the
following grammar, following the ABNF notation defined in [5]. The
filter format uses a prefix notation.
filter = "(" filtercomp ")"
filtercomp = and / or / not / item
and = "&" filterlist
or = "|" filterlist
not = "!" filter
filterlist = 1*filter
item = simple / present / substring / extensible
simple = attr filtertype value
filtertype = equal / approx / greater / less
equal = "="
approx = "~="
greater = ">="
less = "<="
extensible = attr [":dn"] [":" matchingrule] ":=" value
/ [":dn"] ":" matchingrule ":=" value
present = attr "=*"
substring = attr "=" [initial] any [final]
initial = value
any = "*" *(value "*")
final = value
attr = AttributeDescription from Section 4.1.5 of [1]
matchingrule = MatchingRuleId from Section 4.1.9 of [1]
value = AttributeValue from Section 4.1.6 of [1]
The attr, matchingrule, and value constructs are as described in the
corresponding section of [1] given above.
Howes Standards Track [Page 4]
RFC 2254 String Representation of LDAP December 1997
If a value should contain any of the following characters
Character ASCII value
---------------------------
* 0x2a
( 0x28
) 0x29
\ 0x5c
NUL 0x00
the character must be encoded as the backslash '\' character (ASCII
0x5c) followed by the two hexadecimal digits representing the ASCII
value of the encoded character. The case of the two hexadecimal
digits is not significant.
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 characters besides the
ones listed above may be escaped using this mechanism, for example,
non-printing characters.
For example, the filter checking whether the "cn" attribute contained
a value with the character "*" anywhere in it would be represented as
"(cn=*\2a*)".
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.
5. 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*)
The following examples illustrate the use of extensible matching.
(cn:1.2.3.4.5:=Fred Flintstone)
(sn:dn:2.4.6.8.10:=Barney Rubble)
(o:dn:=Ace Industry)
(:dn:2.4.6.8.10:=Dino)
Howes Standards Track [Page 5]
RFC 2254 String Representation of LDAP December 1997
The second example illustrates the use of the ":dn" notation to
indicate that matching rule "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.
The third example denotes an equality match, except that DN
components should be considered part of the entry when doing the
match.
The fourth example is a filter that should be applied to any
attribute supporting the matching rule given (since the attr has been
left off). 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)
The first example shows the use of the escaping mechanism to
represent parenthesis characters. The second shows how to represent a
"*" in a 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-byte value
0x00000004, illustrating the use of the escaping mechanism to
represent arbitrary data, including NUL characters.
The final example illustrates the use of the escaping mechanism to
represent various non-ASCII UTF-8 characters.
6. 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.
Howes Standards Track [Page 6]
RFC 2254 String Representation of LDAP December 1997
7. References
[1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[2] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
2252, December 1997.
[3] Specification of ASN.1 encoding rules: Basic, Canonical, and
Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994.
[4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
10646", RFC 2044, October 1996.
[5] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
8. Author's Address
Tim Howes
Netscape Communications Corp.
501 E. Middlefield Road
Mountain View, CA 94043
USA
Phone: +1 415 937-3419
EMail: howes@netscape.com
Howes Standards Track [Page 7]
RFC 2254 String Representation of LDAP December 1997
9. Full Copyright Statement
Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Howes Standards Track [Page 8]

563
doc/rfc/rfc2255.txt
View file

@ -1,563 +0,0 @@
Network Working Group T. Howes
Request for Comments: 2255 M. Smith
Category: Standards Track Netscape Communications Corp.
December 1997
The LDAP URL Format
1. 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 (1997). All Rights Reserved.
IESG NOTE
This document describes a directory access protocol that provides
both read and update access. Update access requires secure
authentication, but this document does not mandate implementation of
any satisfactory authentication mechanisms.
In accordance with RFC 2026, section 4.4.1, this specification is
being approved by IESG as a Proposed Standard despite this
limitation, for the following reasons:
a. to encourage implementation and interoperability testing of
these protocols (with or without update access) before they
are deployed, and
b. to encourage deployment and use of these protocols in read-only
applications. (e.g. applications where LDAPv3 is used as
a query language for directories which are updated by some
secure mechanism other than LDAP), and
c. to avoid delaying the advancement and deployment of other Internet
standards-track protocols which require the ability to query, but
not update, LDAPv3 directory servers.
Howes & Smith Standards Track [Page 1]
RFC 2255 LDAP URL Format December 1997
Readers are hereby warned that until mandatory authentication
mechanisms are standardized, clients and servers written according to
this specification which make use of update functionality are
UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
Implementors are hereby discouraged from deploying LDAPv3 clients or
servers which implement the update functionality, until a Proposed
Standard for mandatory authentication in LDAPv3 has been approved and
published as an RFC.
2. Abstract
LDAP is the Lightweight Directory Access Protocol, defined in [1],
[2] and [3]. This document describes a format for an LDAP Uniform
Resource Locator. The format describes an LDAP search operation to
perform to retrieve information from an LDAP directory. This document
replaces RFC 1959. It updates 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, so that future
documents can extend their functionality, for example, to provide
access to new LDAPv3 extensions as they are defined.
The key words "MUST", "MAY", and "SHOULD" used in this document are
to be interpreted as described in [6].
Howes & Smith Standards Track [Page 2]
RFC 2255 LDAP URL Format December 1997
3. URL Definition
An LDAP URL begins with the protocol prefix "ldap" and is defined by
the following grammar.
ldapurl = scheme "://" [hostport] ["/"
[dn ["?" [attributes] ["?" [scope]
["?" [filter] ["?" extensions]]]]]]
scheme = "ldap"
attributes = attrdesc *("," attrdesc)
scope = "base" / "one" / "sub"
dn = distinguishedName from Section 3 of [1]
hostport = hostport from Section 5 of RFC 1738 [5]
attrdesc = AttributeDescription from Section 4.1.5 of [2]
filter = filter from Section 4 of [4]
extensions = extension *("," extension)
extension = ["!"] extype ["=" exvalue]
extype = token / xtoken
exvalue = LDAPString from section 4.1.2 of [2]
token = oid from section 4.1 of [3]
xtoken = ("X-" / "x-") token
The "ldap" prefix indicates an entry or entries residing in the LDAP
server running on the given hostname at the given portnumber. The
default LDAP port is TCP port 389. If no hostport is given, the
client must have some apriori knowledge of an appropriate LDAP server
to contact.
The dn is an LDAP Distinguished Name using the string format
described in [1]. It identifies the base object of the LDAP search.
ldapurl = scheme "://" [hostport] ["/"
[dn ["?" [attributes] ["?" [scope]
["?" [filter] ["?" extensions]]]]]]
scheme = "ldap"
attributes = attrdesc *("," attrdesc)
scope = "base" / "one" / "sub"
dn = distinguishedName from Section 3 of [1]
hostport = hostport from Section 5 of RFC 1738 [5]
attrdesc = AttributeDescription from Section 4.1.5 of [2]
filter = filter from Section 4 of [4]
extensions = extension *("," extension)
extension = ["!"] extype ["=" exvalue]
extype = token / xtoken
exvalue = LDAPString from section 4.1.2 of [2]
token = oid from section 4.1 of [3]
xtoken = ("X-" / "x-") token
Howes & Smith Standards Track [Page 3]
RFC 2255 LDAP URL Format December 1997
The "ldap" prefix indicates an entry or entries residing in the LDAP
server running on the given hostname at the given portnumber. The
default LDAP port is TCP port 389. If no hostport is given, the
client must have some apriori knowledge of an appropriate LDAP server
to contact.
The dn is an LDAP Distinguished Name using the string format
described in [1]. It identifies the base object of the LDAP search.
The attributes construct is used to indicate which attributes should
be returned from the entry or entries. Individual attrdesc names are
as defined for AttributeDescription in [2]. 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 (in LDAPv3) by requesting the special attribute name "*").
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. If scope is omitted, a scope of "base" is assumed.
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 [4]. If filter is omitted, a filter of
"(objectClass=*)" is assumed.
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 LDAPv3
extension mechanisms. Extensions may be supported or unsupported by
the client resolving the URL. An extension prefixed with a '!'
character (ASCII 33) is critical. An extension not prefixed with a '
!' character is non-critical.
If an extension is supported by the client, the client MUST obey the
extension if the extension is critical. The client SHOULD obey
supported extensions that are non-critical.
If an extension is unsupported by the client, the client MUST NOT
process the URL if the extension is critical. If an unsupported
extension is non-critical, the client MUST ignore the extension.
Howes & Smith Standards Track [Page 4]
RFC 2255 LDAP URL Format December 1997
If a critical extension cannot be processed successfully by the
client, the client MUST NOT process the URL. If a non-critical
extension cannot be processed successfully by the client, the client
SHOULD ignore the extension.
Extension types prefixed by "X-" or "x-" are reserved for use in
bilateral agreements between communicating parties. Other extension
types MUST be defined in this document, or in other standards-track
documents.
One LDAP URL extension is defined in this document in the next
section. Other documents or a future version of this document MAY
define other extensions.
Note that any URL-illegal characters (e.g., spaces), URL special
characters (as defined in section 2.2 of RFC 1738) and the reserved
character '?' (ASCII 63) occurring inside a dn, filter, or other
element of an LDAP URL MUST be escaped using the % method described
in RFC 1738 [5]. If a comma character ',' occurs inside an extension
value, the character MUST also be escaped using the % method.
4. The Bindname Extension
This section defines an LDAP URL extension for representing the
distinguished name for a client to use when authenticating to an LDAP
directory during resolution of an LDAP URL. Clients MAY implement
this extension.
The extension type is "bindname". The extension value is the
distinguished name of the directory entry to authenticate as, in the
same form as described for dn in the grammar above. The dn may be the
NULL string to specify unauthenticated access. The extension may be
either critical (prefixed with a '!' character) or non-critical (not
prefixed with a '!' character).
If the bindname extension is critical, the client resolving the URL
MUST authenticate to the directory using the given distinguished name
and an appropriate authentication method. Note that for a NULL
distinguished name, no bind MAY be required to obtain anonymous
access to the directory. If the extension is non-critical, the client
MAY bind to the directory using the given distinguished name.
5. URL Processing
This section describes how an LDAP URL SHOULD be resolved by a
client.
Howes & Smith Standards Track [Page 5]
RFC 2255 LDAP URL Format December 1997
First, the client obtains a connection to the LDAP server referenced
in the URL, or an LDAP server of the client's choice if no LDAP
server is explicitly referenced. This connection MAY be opened
specifically for the purpose of resolving the URL or the client MAY
reuse an already open connection. The connection MAY provide
confidentiality, integrity, or other services, e.g., using TLS. Use
of security services is at the client's discretion if not specified
in the URL.
Next, the client authenticates itself to the LDAP server. This step
is optional, unless the URL contains a critical bindname extension
with a non-NULL value. If a bindname extension is given, the client
proceeds according to the section above.
If a bindname extension is not specified, the client MAY bind to the
directory using a appropriate dn and authentication method of its own
choosing (including NULL authentication).
Next, the client performs the LDAP search operation specified in the
URL. Additional fields in the LDAP protocol search request, such as
sizelimit, timelimit, deref, and anything else not specified or
defaulted in the URL specification, MAY be set at the client's
discretion.
Once the search has completed, the client MAY close the connection to
the LDAP server, or the client MAY keep the connection open for
future use.
6. Examples
The following are some example LDAP URLs using 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://ldap.itd.umich.edu/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:
Howes & Smith Standards Track [Page 6]
RFC 2255 LDAP URL Format December 1997
ldap://ldap.itd.umich.edu/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://host.com: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://ldap.itd.umich.edu/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" is given below, illustrating
the use of the escaping mechanism on the reserved character '?'.
ldap://ldap.question.com/o=Question%3f,c=US?mail
The next example illustrates the interaction between LDAP and URL
quoting mechanisms.
ldap://ldap.netscape.com/o=Babsco,c=US??(int=%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 (int=\00\00\00\04). Because the \ character must
be escaped in a URL, the \'s are escaped as %5c in the URL encoding.
The final example shows the use of the bindname extension to specify
the dn a client should use for authentication when resolving the URL.
ldap:///??sub??bindname=cn=Manager%2co=Foo
ldap:///??sub??!bindname=cn=Manager%2co=Foo
The two URLs are the same, except that the second one marks the
bindname extension as critical. Notice the use of the % encoding
method to encode the comma in the distinguished name value in the
Howes & Smith Standards Track [Page 7]
RFC 2255 LDAP URL Format December 1997
bindname extension.
7. Security Considerations
General URL security considerations discussed in [5] 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 about which servers to connect to using which security
mechanisms, and SHOULD NOT make connections that are inconsistent
with this policy.
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 connection. (Note that clients
conforming to previous LDAP URL specifications, where all connections
are anonymous and unprotected, are consistent with this
specification; they simply have the default security policy.)
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 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.
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, the initiation of a long-lived
search, etc. The security implications of resolving an LDAP URL are
the same as those of resolving an LDAP search query.
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.
Howes & Smith Standards Track [Page 8]
RFC 2255 LDAP URL Format December 1997
Several people have made valuable comments on this document. In
particular RL "Bob" Morgan and Mark Wahl deserve special thanks for
their contributions.
9. References
[1] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished Names",
RFC 2253, December 1997.
[2] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[3] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
2252, December 1997.
[4] Howes, T., "A String Representation of LDAP Search Filters", RFC
2254, December 1997.
[5] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
Locators (URL)," RFC 1738, December 1994.
[6] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
Levels," RFC 2119, March 1997.
Authors' Addresses
Tim Howes
Netscape Communications Corp.
501 E. Middlefield Rd.
Mountain View, CA 94043
USA
Phone: +1 415 937-3419
EMail: howes@netscape.com
Mark Smith
Netscape Communications Corp.
501 E. Middlefield Rd.
Mountain View, CA 94043
USA
Phone: +1 415 937-3477
EMail: mcs@netscape.com
Howes & Smith Standards Track [Page 9]
RFC 2255 LDAP URL Format December 1997
Full Copyright Statement
Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Howes & Smith Standards Track [Page 10]

1123
doc/rfc/rfc2256.txt
View file

File diff suppressed because it is too large Load diff

451
doc/rfc/rfc2587.txt
View file

@ -1,451 +0,0 @@
Network Working Group S. Boeyen
Request for Comments: 2587 Entrust
Category: Standards Track T. Howes
Netscape
P. Richard
Xcert
June 1999
Internet X.509 Public Key Infrastructure
LDAPv2 Schema
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 (1999). All Rights Reserved.
1. Abstract
The schema defined in this document is a minimal schema to support
PKIX in an LDAPv2 environment, as defined in RFC 2559. Only PKIX-
specific components are specified here. LDAP servers, acting as PKIX
repositories should support the auxiliary object classes defined in
this specification and integrate this schema specification with the
generic and other application-specific schemas as appropriate,
depending on the services to be supplied by that server.
The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED',
and 'MAY' in this document are to be interpreted as described in RFC
2119.
2. Introduction
This specification is part of a multi-part standard for development
of a Public Key Infrastructure (PKI) for the Internet. LDAPv2 is one
mechanism defined for access to a PKI repository. Other mechanisms,
such as http, are also defined. If an LDAP server, accessed by LDAPv2
is used to provide a repository, the minimum requirement is that the
repository support the addition of X.509 certificates to directory
Boeyen, et al. Standards Track [Page 1]
RFC 2587 PKIX LDAPv2 Schema June 1999
entries. Certificate Revocation List (CRL)is one mechanism for
publishing revocation information in a repository. Other mechanisms,
such as http, are also defined.
This specification defines the attributes and object classes to be
used by LDAP servers acting as PKIX repositories and to be understood
by LDAP clients communicating with such repositories to query, add,
modify and delete PKI information. Some object classes and attributes
defined in X.509 are duplicated here for completeness. For end
entities and Certification Authorities (CA), the earlier X.509
defined object classes mandated inclusion of attributes which are
optional for PKIX. Also, because of the mandatory attribute
specification, this would have required dynamic modification of the
object class attribute should the attributes not always be present in
entries. For these reasons, alternative object classes are defined in
this document for use by LDAP servers acting as PKIX repositories.
3. PKIX Repository Objects
The primary PKIX objects to be represented in a repository are:
- End Entities
- Certification Authorities (CA)
These objects are defined in RFC 2459.
3.1. End Entities
For purposes of PKIX schema definition, the role of end entities as
subjects of certificates is the major aspect relevant to this
specification. End entities may be human users, or other types of
entities to which certificates may be issued. In some cases, the
entry for the end entity may already exist and the PKI-specific
information is added to the existing entry. In other cases the entry
may not exist prior to the issuance of a certificate, in which case
the entity adding the certificate may also need to create the entry.
Schema elements used to represent the non PKIX aspects of an entry,
such as the structural object class used to represent organizational
persons, may vary, depending on the particular environment and set of
applications served and are outside the scope of this specification.
The following auxiliary object class MAY be used to represent
certificate subjects:
Boeyen, et al. Standards Track [Page 2]
RFC 2587 PKIX LDAPv2 Schema June 1999
pkiUser OBJECT-CLASS ::= {
SUBCLASS OF { top}
KIND auxiliary
MAY CONTAIN {userCertificate}
ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiUser(21)}
userCertificate ATTRIBUTE ::= {
WITH SYNTAX Certificate
EQUALITY MATCHING RULE certificateExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4) userCertificate(36) }
An end entity may obtain one or more certificates from one or more
Certification Authorities. The userCertificate attribute MUST be
used to represent these certificates in the directory entry
representing that user.
3.2. Certification Authorities
As with end entities, Certification Authorities are typically
represented in directories as auxiliary components of entries
representing a more generic object, such as organizations,
organizational units etc. The non PKIX-specific schema elements for
these entries, such as the structural object class of the object, are
outside the scope of this specification.
The following auxiliary object class MAY be used to represent
Certification Authorities:
pkiCA OBJECT-CLASS ::= {
SUBCLASS OF { top}
KIND auxiliary
MAY CONTAIN {cACertificate |
certificateRevocationList |
authorityRevocationList |
crossCertificatePair }
ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22)}
cACertificate ATTRIBUTE ::= {
WITH SYNTAX Certificate
EQUALITY MATCHING RULE certificateExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4) cACertificate(37) }
crossCertificatePairATTRIBUTE::={
WITH SYNTAX CertificatePair
EQUALITY MATCHING RULE certificatePairExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40)}
Boeyen, et al. Standards Track [Page 3]
RFC 2587 PKIX LDAPv2 Schema June 1999
The cACertificate attribute of a CA's directory entry shall be used
to store self-issued certificates (if any) and certificates issued to
this CA by CAs in the same realm as this CA.
The forward elements of the crossCertificatePair attribute of a CA's
directory entry shall be used to store all, except self-issued
certificates issued to this CA. Optionally, the reverse elements of
the crossCertificatePair attribute, of a CA's directory entry may
contain a subset of certificates issued by this CA to other CAs.
When both the forward and the reverse elements are present in a
single attribute value, issuer name in one certificate shall match
the subject name in the other and vice versa, and the subject public
key in one certificate shall be capable of verifying the digital
signature on the other certificate and vice versa.
When a reverse element is present, the forward element value and the
reverse element value need not be stored in the same attribute value;
in other words, they can be stored in either a single attribute value
or two attribute values.
In the case of V3 certificates, none of the above CA certificates
shall include a basicConstraints extension with the cA value set to
FALSE.
The definition of realm is purely a matter of local policy.
certificateRevocationListATTRIBUTE::={
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4)
certificateRevocationList(39)}
The certificateRevocationList attribute, if present in a particular
CA's entry, contains CRL(s) as defined in RFC 2459.
authorityRevocationListATTRIBUTE::={
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4)
authorityRevocationList(38)}
The authorityRevocationList attribute, if present in a particular
CA's entry, includes revocation information regarding certificates
issued to other CAs.
Boeyen, et al. Standards Track [Page 4]
RFC 2587 PKIX LDAPv2 Schema June 1999
3.2.1. CRL distribution points
CRL distribution points are an optional mechanism, specified in RFC
2459, which MAY be used to distribute revocation information.
A patent statement regarding CRL distribution points can be found at
the end of this document.
If a CA elects to use CRL distribution points, the following object
class is used to represent these.
cRLDistributionPoint OBJECT-CLASS::= {
SUBCLASS OF { top }
KIND structural
MUST CONTAIN { commonName }
MAY CONTAIN { certificateRevocationList |
authorityRevocationList |
deltaRevocationList }
ID joint-iso-ccitt(2) ds(5) objectClass(6) cRLDistributionPoint(19) }
The certificateRevocationList and authorityRevocationList attributes
are as defined above.
The commonName attribute and deltaRevocationList attributes, defined
in X.509, are duplicated below.
commonName ATTRIBUTE::={
SUBTYPE OF name
WITH SYNTAX DirectoryString
ID joint-iso-ccitt(2) ds(5) attributeType(4) commonName(3) }
deltaRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4)
deltaRevocationList(53) }
3.2.2. Delta CRLs
Delta CRLs are an optional mechanism, specified in RFC 2459, which
MAY be used to enhance the distribution of revocation information.
If a CA elects to use delta CRLs, the following object class is used
to represent these.
Boeyen, et al. Standards Track [Page 5]
RFC 2587 PKIX LDAPv2 Schema June 1999
deltaCRL OBJECT-CLASS::= {
SUBCLASS OF { top }
KIND auxiliary
MAY CONTAIN { deltaRevocationList }
ID joint-iso-ccitt(2) ds(5) objectClass(6) deltaCRL(23) }
4. Security Considerations
Since the elements of information which are key to the PKI service
(certificates and CRLs) are both digitally signed pieces of
information, no additional integrity service is REQUIRED.
Security considerations with respect to retrieval, addition,
deletion, and modification of the information supported by this
schema definition are addressed in RFC 2559.
5. References
[1] Yeong, Y., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol", RFC 1777, March 1995.
[2] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
6 Intellectual Property Rights
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
Boeyen, et al. Standards Track [Page 6]
RFC 2587 PKIX LDAPv2 Schema June 1999
7. Authors' Addresses
Sharon Boeyen
Entrust Technologies Limited
750 Heron Road
Ottawa, Ontario
Canada K1V 1A7
EMail: sharon.boeyen@entrust.com
Tim Howes
Netscape Communications Corp.
501 E. Middlefield Rd.
Mountain View, CA 94043
USA
EMail: howes@netscape.com
Patrick Richard
Xcert Software Inc.
Suite 1001, 701 W. Georgia Street
P.O. Box 10145
Pacific Centre
Vancouver, B.C.
Canada V7Y 1C6
EMail: patr@xcert.com
Boeyen, et al. Standards Track [Page 7]
RFC 2587 PKIX LDAPv2 Schema June 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Boeyen, et al. Standards Track [Page 8]

899
doc/rfc/rfc2829.txt
View file

@ -1,899 +0,0 @@
Network Working Group M. Wahl
Request for Comments: 2829 Sun Microsystems, Inc.
Category: Standards Track H. Alvestrand
EDB Maxware
J. Hodges
Oblix, Inc.
R. Morgan
University of Washington
May 2000
Authentication Methods for LDAP
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 (2000). All Rights Reserved.
Abstract
This document specifies particular combinations of security
mechanisms which are required and recommended in LDAP [1]
implementations.
1. Introduction
LDAP version 3 is a powerful access protocol for directories.
It offers means of searching, fetching and manipulating directory
content, and ways to access a rich set of security functions.
In order to function for the best of the Internet, it is vital that
these security functions be interoperable; therefore there has to be
a minimum subset of security functions that is common to all
implementations that claim LDAPv3 conformance.
Basic threats to an LDAP directory service include:
(1) Unauthorized access to data via data-fetching operations,
Wahl, et al. Standards Track [Page 1]
RFC 2829 Authentication Methods for LDAP May 2000
(2) Unauthorized access to reusable client authentication
information by monitoring others' access,
(3) Unauthorized access to data by monitoring others' access,
(4) Unauthorized modification of data,
(5) Unauthorized modification of configuration,
(6) Unauthorized or excessive use of resources (denial of
service), and
(7) Spoofing of directory: Tricking a client into believing that
information came from the directory when in fact it did not,
either by modifying data in transit or misdirecting the
client's connection.
Threats (1), (4), (5) and (6) are due to hostile clients. Threats
(2), (3) and (7) are due to hostile agents on the path between client
and server, or posing as a server.
The LDAP protocol suite can be protected with the following security
mechanisms:
(1) Client authentication by means of the SASL [2] mechanism
set, possibly backed by the TLS credentials exchange
mechanism,
(2) Client authorization by means of access control based on the
requestor's authenticated identity,
(3) Data integrity protection by means of the TLS protocol or
data-integrity SASL mechanisms,
(4) Protection against snooping by means of the TLS protocol or
data-encrypting SASL mechanisms,
(5) Resource limitation by means of administrative limits on
service controls, and
(6) Server authentication by means of the TLS protocol or SASL
mechanism.
At the moment, imposition of access controls is done by means outside
the scope of the LDAP protocol.
In this document, the term "user" represents any application which is
an LDAP client using the directory to retrieve or store information.
Wahl, et al. Standards Track [Page 2]
RFC 2829 Authentication Methods for LDAP May 2000
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
2. Example deployment scenarios
The following scenarios are typical for LDAP directories on the
Internet, and have different security requirements. (In the
following, "sensitive" means data that will cause real damage to the
owner if revealed; there may be data that is protected but not
sensitive). This is not intended to be a comprehensive list, other
scenarios are possible, especially on physically protected networks.
(1) A read-only directory, containing no sensitive data,
accessible to "anyone", and TCP connection hijacking or IP
spoofing is not a problem. This directory requires no
security functions except administrative service limits.
(2) A read-only directory containing no sensitive data; read
access is granted based on identity. TCP connection
hijacking is not currently a problem. This scenario requires
a secure authentication function.
(3) A read-only directory containing no sensitive data; and the
client needs to ensure that the directory data is
authenticated by the server and not modified while being
returned from the server.
(4) A read-write directory, containing no sensitive data; read
access is available to "anyone", update access to properly
authorized persons. TCP connection hijacking is not
currently a problem. This scenario requires a secure
authentication function.
(5) A directory containing sensitive data. This scenario
requires session confidentiality protection AND secure
authentication.
3. Authentication and Authorization: Definitions and Concepts
This section defines basic terms, concepts, and interrelationships
regarding authentication, authorization, credentials, and identity.
These concepts are used in describing how various security approaches
are utilized in client authentication and authorization.
Wahl, et al. Standards Track [Page 3]
RFC 2829 Authentication Methods for LDAP May 2000
3.1. Access Control Policy
An access control policy is a set of rules defining the protection of
resources, generally in terms of the capabilities of persons or other
entities accessing those resources. A common expression of an access
control policy is an access control list. Security objects and
mechanisms, such as those described here, enable the expression of
access control policies and their enforcement. Access control
policies are typically expressed in terms of access control
attributes as described below.
3.2. Access Control Factors
A request, when it is being processed by a server, may be associated
with a wide variety of security-related factors (section 4.2 of [1]).
The server uses these factors to determine whether and how to process
the request. These are called access control factors (ACFs). They
might include source IP address, encryption strength, the type of
operation being requested, time of day, etc. Some factors may be
specific to the request itself, others may be associated with the
connection via which the request is transmitted, others (e.g. time of
day) may be "environmental".
Access control policies are expressed in terms of access control
factors. E.g., a request having ACFs i,j,k can perform operation Y
on resource Z. The set of ACFs that a server makes available for such
expressions is implementation-specific.
3.3. Authentication, Credentials, Identity
Authentication credentials are the evidence supplied by one party to
another, asserting the identity of the supplying party (e.g. a user)
who is attempting to establish an association with the other party
(typically a server). Authentication is the process of generating,
transmitting, and verifying these credentials and thus the identity
they assert. An authentication identity is the name presented in a
credential.
There are many forms of authentication credentials -- the form used
depends upon the particular authentication mechanism negotiated by
the parties. For example: X.509 certificates, Kerberos tickets,
simple identity and password pairs. Note that an authentication
mechanism may constrain the form of authentication identities used
with it.
Wahl, et al. Standards Track [Page 4]
RFC 2829 Authentication Methods for LDAP May 2000
3.4. Authorization Identity
An authorization identity is one kind of access control factor. It
is the name of the user or other entity that requests that operations
be performed. Access control policies are often expressed in terms
of authorization identities; e.g., entity X can perform operation Y
on resource Z.
The authorization identity bound to an association is often exactly
the same as the authentication identity presented by the client, but
it may be different. SASL allows clients to specify an authorization
identity distinct from the authentication identity asserted by the
client's credentials. This permits agents such as proxy servers to
authenticate using their own credentials, yet request the access
privileges of the identity for which they are proxying [2]. Also,
the form of authentication identity supplied by a service like TLS
may not correspond to the authorization identities used to express a
server's access control policy, requiring a server-specific mapping
to be done. The method by which a server composes and validates an
authorization identity from the authentication credentials supplied
by a client is implementation-specific.
4. Required security mechanisms
It is clear that allowing any implementation, faced with the above
requirements, to pick and choose among the possible alternatives is
not a strategy that is likely to lead to interoperability. In the
absence of mandates, clients will be written that do not support any
security function supported by the server, or worse, support only
mechanisms like cleartext passwords that provide clearly inadequate
security.
Active intermediary attacks are the most difficult for an attacker to
perform, and for an implementation to protect against. Methods that
protect only against hostile client and passive eavesdropping attacks
are useful in situations where the cost of protection against active
intermediary attacks is not justified based on the perceived risk of
active intermediary attacks.
Given the presence of the Directory, there is a strong desire to see
mechanisms where identities take the form of a Distinguished Name and
authentication data can be stored in the directory; this means that
either this data is useless for faking authentication (like the Unix
"/etc/passwd" file format used to be), or its content is never passed
across the wire unprotected - that is, it's either updated outside
the protocol or it is only updated in sessions well protected against
snooping. It is also desirable to allow authentication methods to
Wahl, et al. Standards Track [Page 5]
RFC 2829 Authentication Methods for LDAP May 2000
carry authorization identities based on existing forms of user
identities for backwards compatibility with non-LDAP-based
authentication services.
Therefore, the following implementation conformance requirements are
in place:
(1) For a read-only, public directory, anonymous authentication,
described in section 5, can be used.
(2) Implementations providing password-based authenticated
access MUST support authentication using the DIGEST-MD5 SASL
mechanism [4], as described in section 6.1. This provides
client authentication with protection against passive
eavesdropping attacks, but does not provide protection
against active intermediary attacks.
(3) For a directory needing session protection and
authentication, the Start TLS extended operation [5], and
either the simple authentication choice or the SASL EXTERNAL
mechanism, are to be used together. Implementations SHOULD
support authentication with a password as described in
section 6.2, and SHOULD support authentication with a
certificate as described in section 7.1. Together, these
can provide integrity and disclosure protection of
transmitted data, and authentication of client and server,
including protection against active intermediary attacks.
If TLS is negotiated, the client MUST discard all information about
the server fetched prior to the TLS negotiation. In particular, the
value of supportedSASLMechanisms MAY be different after TLS has been
negotiated (specifically, the EXTERNAL mechanism or the proposed
PLAIN mechanism are likely to only be listed after a TLS negotiation
has been performed).
If a SASL security layer is negotiated, the client MUST discard all
information about the server fetched prior to SASL. In particular,
if the client is configured to support multiple SASL mechanisms, it
SHOULD fetch supportedSASLMechanisms both before and after the SASL
security layer is negotiated and verify that the value has not
changed after the SASL security layer was negotiated. This detects
active attacks which remove supported SASL mechanisms from the
supportedSASLMechanisms list, and allows the client to ensure that it
is using the best mechanism supported by both client and server
(additionally, this is a SHOULD to allow for environments where the
supported SASL mechanisms list is provided to the client through a
different trusted source, e.g. as part of a digitally signed object).
Wahl, et al. Standards Track [Page 6]
RFC 2829 Authentication Methods for LDAP May 2000
5. Anonymous authentication
Directory operations which modify entries or access protected
attributes or entries generally require client authentication.
Clients which do not intend to perform any of these operations
typically use anonymous authentication.
LDAP implementations MUST support anonymous authentication, as
defined in section 5.1.
LDAP implementations MAY support anonymous authentication with TLS,
as defined in section 5.2.
While there MAY be access control restrictions to prevent access to
directory entries, an LDAP server SHOULD allow an anonymously-bound
client to retrieve the supportedSASLMechanisms attribute of the root
DSE.
An LDAP server MAY use other information about the client provided by
the lower layers or external means to grant or deny access even to
anonymously authenticated clients.
5.1. Anonymous authentication procedure
An LDAP client which has not successfully completed a bind operation
on a connection is anonymously authenticated.
An LDAP client MAY also specify anonymous authentication in a bind
request by using a zero-length OCTET STRING with the simple
authentication choice.
5.2. Anonymous authentication and TLS
An LDAP client MAY use the Start TLS operation [5] to negotiate the
use of TLS security [6]. If the client has not bound beforehand,
then until the client uses the EXTERNAL SASL mechanism to negotiate
the recognition of the client's certificate, the client is
anonymously authenticated.
Recommendations on TLS ciphersuites are given in section 10.
An LDAP server which requests that clients provide their certificate
during TLS negotiation MAY use a local security policy to determine
whether to successfully complete TLS negotiation if the client did
not present a certificate which could be validated.
Wahl, et al. Standards Track [Page 7]
RFC 2829 Authentication Methods for LDAP May 2000
6. Password-based authentication
LDAP implementations MUST support authentication with a password
using the DIGEST-MD5 SASL mechanism for password protection, as
defined in section 6.1.
LDAP implementations SHOULD support authentication with the "simple"
password choice when the connection is protected against
eavesdropping using TLS, as defined in section 6.2.
6.1. Digest authentication
An LDAP client MAY determine whether the server supports this
mechanism by performing a search request on the root DSE, requesting
the supportedSASLMechanisms attribute, and checking whether the
string "DIGEST-MD5" is present as a value of this attribute.
In the first stage of authentication, when the client is performing
an "initial authentication" as defined in section 2.1 of [4], the
client sends a bind request in which the version number is 3, the
authentication choice is sasl, the sasl mechanism name is "DIGEST-
MD5", and the credentials are absent. The client then waits for a
response from the server to this request.
The server will respond with a bind response in which the resultCode
is saslBindInProgress, and the serverSaslCreds field is present. The
contents of this field is a string defined by "digest-challenge" in
section 2.1.1 of [4]. The server SHOULD include a realm indication
and MUST indicate support for UTF-8.
The client will send a bind request with a distinct message id, in
which the version number is 3, the authentication choice is sasl, the
sasl mechanism name is "DIGEST-MD5", and the credentials contain the
string defined by "digest-response" in section 2.1.2 of [4]. The
serv-type is "ldap".
The server will respond with a bind response in which the resultCode
is either success, or an error indication. If the authentication is
successful and the server does not support subsequent authentication,
then the credentials field is absent. If the authentication is
successful and the server supports subsequent authentication, then
the credentials field contains the string defined by "response-auth"
in section 2.1.3 of [4]. Support for subsequent authentication is
OPTIONAL in clients and servers.
Wahl, et al. Standards Track [Page 8]
RFC 2829 Authentication Methods for LDAP May 2000
6.2. "simple" authentication choice under TLS encryption
A user who has a directory entry containing a userPassword attribute
MAY authenticate to the directory by performing a simple password
bind sequence following the negotiation of a TLS ciphersuite
providing connection confidentiality [6].
The client will use the Start TLS operation [5] to negotiate the use
of TLS security [6] on the connection to the LDAP server. The client
need not have bound to the directory beforehand.
For this authentication procedure to be successful, the client and
server MUST negotiate a ciphersuite which contains a bulk encryption
algorithm of appropriate strength. Recommendations on cipher suites
are given in section 10.
Following the successful completion of TLS negotiation, the client
MUST send an LDAP bind request with the version number of 3, the name
field containing the name of the user's entry, and the "simple"
authentication choice, containing a password.
The server will, for each value of the userPassword attribute in the
named user's entry, compare these for case-sensitive equality with
the client's presented password. If there is a match, then the
server will respond with resultCode success, otherwise the server
will respond with resultCode invalidCredentials.
6.3. Other authentication choices with TLS
It is also possible, following the negotiation of TLS, to perform a
SASL authentication which does not involve the exchange of plaintext
reusable passwords. In this case the client and server need not
negotiate a ciphersuite which provides confidentiality if the only
service required is data integrity.
7. Certificate-based authentication
LDAP implementations SHOULD support authentication via a client
certificate in TLS, as defined in section 7.1.
7.1. Certificate-based authentication with TLS
A user who has a public/private key pair in which the public key has
been signed by a Certification Authority may use this key pair to
authenticate to the directory server if the user's certificate is
requested by the server. The user's certificate subject field SHOULD
be the name of the user's directory entry, and the Certification
Authority must be sufficiently trusted by the directory server to
Wahl, et al. Standards Track [Page 9]
RFC 2829 Authentication Methods for LDAP May 2000
have issued the certificate in order that the server can process the
certificate. The means by which servers validate certificate paths
is outside the scope of this document.
A server MAY support mappings for certificates in which the subject
field name is different from the name of the user's directory entry.
A server which supports mappings of names MUST be capable of being
configured to support certificates for which no mapping is required.
The client will use the Start TLS operation [5] to negotiate the use
of TLS security [6] on the connection to the LDAP server. The client
need not have bound to the directory beforehand.
In the TLS negotiation, the server MUST request a certificate. The
client will provide its certificate to the server, and MUST perform a
private key-based encryption, proving it has the private key
associated with the certificate.
As deployments will require protection of sensitive data in transit,
the client and server MUST negotiate a ciphersuite which contains a
bulk encryption algorithm of appropriate strength. Recommendations
of cipher suites are given in section 10.
The server MUST verify that the client's certificate is valid. The
server will normally check that the certificate is issued by a known
CA, and that none of the certificates on the client's certificate
chain are invalid or revoked. There are several procedures by which
the server can perform these checks.
Following the successful completion of TLS negotiation, the client
will send an LDAP bind request with the SASL "EXTERNAL" mechanism.
8. Other mechanisms
The LDAP "simple" authentication choice is not suitable for
authentication on the Internet where there is no network or transport
layer confidentiality.
As LDAP includes native anonymous and plaintext authentication
methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are not used
with LDAP. If an authorization identity of a form different from a
DN is requested by the client, a mechanism that protects the password
in transit SHOULD be used.
The following SASL-based mechanisms are not considered in this
document: KERBEROS_V4, GSSAPI and SKEY.
Wahl, et al. Standards Track [Page 10]
RFC 2829 Authentication Methods for LDAP May 2000
The "EXTERNAL" SASL mechanism can be used to request the LDAP server
make use of security credentials exchanged by a lower layer. If a TLS
session has not been established between the client and server prior
to making the SASL EXTERNAL Bind request and there is no other
external source of authentication credentials (e.g. IP-level
security [8]), or if, during the process of establishing the TLS
session, the server did not request the client's authentication
credentials, the SASL EXTERNAL bind MUST fail with a result code of
inappropriateAuthentication. Any client authentication and
authorization state of the LDAP association is lost, so the LDAP
association is in an anonymous state after the failure.
9. Authorization Identity
The authorization identity is carried as part of the SASL credentials
field in the LDAP Bind request and response.
When the "EXTERNAL" mechanism is being negotiated, if the credentials
field is present, it contains an authorization identity of the
authzId form described below.
Other mechanisms define the location of the authorization identity in
the credentials field.
The authorization identity is a string in the UTF-8 character set,
corresponding to the following ABNF [7]:
; Specific predefined authorization (authz) id schemes are
; defined below -- new schemes may be defined in the future.
authzId = dnAuthzId / uAuthzId
; distinguished-name-based authz id.
dnAuthzId = "dn:" dn
dn = utf8string ; with syntax defined in RFC 2253
; unspecified userid, UTF-8 encoded.
uAuthzId = "u:" userid
userid = utf8string ; syntax unspecified
A utf8string is defined to be the UTF-8 encoding of one or more ISO
10646 characters.
All servers which support the storage of authentication credentials,
such as passwords or certificates, in the directory MUST support the
dnAuthzId choice.
Wahl, et al. Standards Track [Page 11]
RFC 2829 Authentication Methods for LDAP May 2000
The uAuthzId choice allows for compatibility with client applications
which wish to authenticate to a local directory but do not know their
own Distinguished Name or have a directory entry. The format of the
string is defined as only a sequence of UTF-8 encoded ISO 10646
characters, and further interpretation is subject to prior agreement
between the client and server.
For example, the userid could identify a user of a specific directory
service, or be a login name or the local-part of an RFC 822 email
address. In general a uAuthzId MUST NOT be assumed to be globally
unique.
Additional authorization identity schemes MAY be defined in future
versions of this document.
10. TLS Ciphersuites
The following ciphersuites defined in [6] MUST NOT be used for
confidentiality protection of passwords or data:
TLS_NULL_WITH_NULL_NULL
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
The following ciphersuites defined in [6] can be cracked easily (less
than a week of CPU time on a standard CPU in 1997). The client and
server SHOULD carefully consider the value of the password or data
being protected before using these ciphersuites:
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
The following ciphersuites are vulnerable to man-in-the-middle
attacks, and SHOULD NOT be used to protect passwords or sensitive
data, unless the network configuration is such that the danger of a
man-in-the-middle attack is tolerable:
Wahl, et al. Standards Track [Page 12]
RFC 2829 Authentication Methods for LDAP May 2000
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
A client or server that supports TLS MUST support at least
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
11. SASL service name for LDAP
For use with SASL [2], a protocol must specify a service name to be
used with various SASL mechanisms, such as GSSAPI. For LDAP, the
service name is "ldap", which has been registered with the IANA as a
GSSAPI service name.
12. Security Considerations
Security issues are discussed throughout this memo; the
(unsurprising) conclusion is that mandatory security is important,
and that session encryption is required when snooping is a problem.
Servers are encouraged to prevent modifications by anonymous users.
Servers may also wish to minimize denial of service attacks by timing
out idle connections, and returning the unwillingToPerform result
code rather than performing computationally expensive operations
requested by unauthorized clients.
A connection on which the client has not performed the Start TLS
operation or negotiated a suitable SASL mechanism for connection
integrity and encryption services is subject to man-in-the-middle
attacks to view and modify information in transit.
Additional security considerations relating to the EXTERNAL mechanism
to negotiate TLS can be found in [2], [5] and [6].
13. Acknowledgements
This document is a product of the LDAPEXT Working Group of the IETF.
The contributions of its members is greatly appreciated.
Wahl, et al. Standards Track [Page 13]
RFC 2829 Authentication Methods for LDAP May 2000
14. Bibliography
[1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[2] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC
2222, October 1997.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Leach, P. and C. Newman, "Using Digest Authentication as a SASL
Mechanism", RFC 2831, May 2000.
[5] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory Access
Protocol (v3): Extension for Transport Layer Security", RFC 2830,
May 2000.
[6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[7] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[8] Kent, S. and R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
Wahl, et al. Standards Track [Page 14]
RFC 2829 Authentication Methods for LDAP May 2000
15. Authors' Addresses
Mark Wahl
Sun Microsystems, Inc.
8911 Capital of Texas Hwy #4140
Austin TX 78759
USA
EMail: M.Wahl@innosoft.com
Harald Tveit Alvestrand
EDB Maxware
Pirsenteret
N-7462 Trondheim, Norway
Phone: +47 73 54 57 97
EMail: Harald@Alvestrand.no
Jeff Hodges
Oblix, Inc.
18922 Forge Drive
Cupertino, CA 95014
USA
Phone: +1-408-861-6656
EMail: JHodges@oblix.com
RL "Bob" Morgan
Computing and Communications
University of Washington
Seattle, WA 98105
USA
Phone: +1-206-221-3307
EMail: rlmorgan@washington.edu
Wahl, et al. Standards Track [Page 15]
RFC 2829 Authentication Methods for LDAP May 2000
16. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Wahl, et al. Standards Track [Page 16]

675
doc/rfc/rfc2830.txt
View file

@ -1,675 +0,0 @@
Network Working Group J. Hodges
Request for Comments: 2830 Oblix Inc.
Category: Standards Track R. Morgan
Univ of Washington
M. Wahl
Sun Microsystems, Inc.
May 2000
Lightweight Directory Access Protocol (v3):
Extension for Transport Layer Security
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 (2000). All Rights Reserved.
Abstract
This document defines the "Start Transport Layer Security (TLS)
Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS
establishment in an LDAP association and is defined in terms of an
LDAP extended request.
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 [ReqsKeywords].
2. The Start TLS Request
This section describes the Start TLS extended request and extended
response themselves: how to form the request, the form of the
response, and enumerates the various result codes the client MUST be
prepared to handle.
The section following this one then describes how to sequence an
overall Start TLS Operation.
Hodges, et al. Standards Track [Page 1]
RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
2.1. Requesting TLS Establishment
A client may perform a Start TLS operation by transmitting an LDAP
PDU containing an ExtendedRequest [LDAPv3] specifying the OID for the
Start TLS operation:
1.3.6.1.4.1.1466.20037
An LDAP ExtendedRequest is defined as follows:
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
A Start TLS extended request is formed by setting the requestName
field to the OID string given above. The requestValue field is
absent. The client MUST NOT send any PDUs on this connection
following this request until it receives a Start TLS extended
response.
When a Start TLS extended request is made, the server MUST return an
LDAP PDU containing a Start TLS extended response. An LDAP
ExtendedResponse is defined as follows:
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL }
A Start TLS extended response MUST contain a responseName field which
MUST be set to the same string as that in the responseName field
present in the Start TLS extended request. The response field is
absent. The server MUST set the resultCode field to either success or
one of the other values outlined in section 2.3.
2.2. "Success" Response
If the ExtendedResponse contains a resultCode of success, this
indicates that the server is willing and able to negotiate TLS. Refer
to section 3, below, for details.
2.3. Response other than "success"
If the ExtendedResponse contains a resultCode other than success,
this indicates that the server is unwilling or unable to negotiate
TLS.
Hodges, et al. Standards Track [Page 2]
RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
If the Start TLS extended request was not successful, the resultCode
will be one of:
operationsError (operations sequencing incorrect; e.g. TLS already
established)
protocolError (TLS not supported or incorrect PDU structure)
referral (this server doesn't do TLS, try this one)
unavailable (e.g. some major problem with TLS, or server is
shutting down)
The server MUST return operationsError if the client violates any of
the Start TLS extended operation sequencing requirements described in
section 3, below.
If the server does not support TLS (whether by design or by current
configuration), it MUST set the resultCode to protocolError (see
section 4.1.1 of [LDAPv3]), or to referral. The server MUST include
an actual referral value in the LDAP Result if it returns a
resultCode of referral. The client's current session is unaffected if
the server does not support TLS. The client MAY proceed with any LDAP
operation, or it MAY close the connection.
The server MUST return unavailable if it supports TLS but cannot
establish a TLS connection for some reason, e.g. the certificate
server not responding, it cannot contact its TLS implementation, or
if the server is in process of shutting down. The client MAY retry
the StartTLS operation, or it MAY proceed with any other LDAP
operation, or it MAY close the connection.
3. Sequencing of the Start TLS Operation
This section describes the overall procedures clients and servers
MUST follow for TLS establishment. These procedures take into
consideration various aspects of the overall security of the LDAP
association including discovery of resultant security level and
assertion of the client's authorization identity.
Note that the precise effects, on a client's authorization identity,
of establishing TLS on an LDAP association are described in detail in
section 5.
Hodges, et al. Standards Track [Page 3]
RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
3.1. Requesting to Start TLS on an LDAP Association
The client MAY send the Start TLS extended request at any time after
establishing an LDAP association, except that in the following cases
the client MUST NOT send a Start TLS extended request:
- if TLS is currently established on the connection, or
- during a multi-stage SASL negotiation, or
- if there are any LDAP operations outstanding on the connection.
The result of violating any of these requirements is a resultCode of
operationsError, as described above in section 2.3.
The client MAY have already performed a Bind operation when it sends
a Start TLS request, or the client might have not yet bound.
If the client did not establish a TLS connection before sending any
other requests, and the server requires the client to establish a TLS
connection before performing a particular request, the server MUST
reject that request with a confidentialityRequired or
strongAuthRequired result. The client MAY send a Start TLS extended
request, or it MAY choose to close the connection.
3.2. Starting TLS
The server will return an extended response with the resultCode of
success if it is willing and able to negotiate TLS. It will return
other resultCodes, documented above, if it is unable.
In the successful case, the client, which has ceased to transfer LDAP
requests on the connection, MUST either begin a TLS negotiation or
close the connection. The client will send PDUs in the TLS Record
Protocol directly over the underlying transport connection to the
server to initiate TLS negotiation [TLS].
3.3. TLS Version Negotiation
Negotiating the version of TLS or SSL to be used is a part of the TLS
Handshake Protocol, as documented in [TLS]. Please refer to that
document for details.
3.4. Discovery of Resultant Security Level
After a TLS connection is established on an LDAP association, both
parties MUST individually decide whether or not to continue based on
the privacy level achieved. Ascertaining the TLS connection's privacy
level is implementation dependent, and accomplished by communicating
with one's respective local TLS implementation.
Hodges, et al. Standards Track [Page 4]
RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
If the client or server decides that the level of authentication or
privacy is not high enough for it to continue, it SHOULD gracefully
close the TLS connection immediately after the TLS negotiation has
completed (see sections 4.1 and 5.2, below).
The client MAY attempt to Start TLS again, or MAY send an unbind
request, or send any other LDAP request.
3.5. Assertion of Client's Authorization Identity
The client MAY, upon receipt of a Start TLS extended response
indicating success, assert that a specific authorization identity be
utilized in determining the client's authorization status. The client
accomplishes this via an LDAP Bind request specifying a SASL
mechanism of "EXTERNAL" [SASL]. See section 5.1.2, below.
3.6. Server Identity Check
The client MUST check its understanding of the server's hostname
against the server's identity as presented in the server's
Certificate message, in order to prevent man-in-the-middle attacks.
Matching is performed according to these rules:
- The client MUST use the server hostname it used to open the LDAP
connection as the value to compare against the server name as
expressed in the server's certificate. The client MUST NOT use the
server's canonical DNS name or any other derived form of name.
- If a subjectAltName extension of type dNSName is present in the
certificate, it SHOULD be used as the source of the server's
identity.
- Matching is case-insensitive.
- The "*" wildcard character is allowed. If present, it applies only
to the left-most name component.
E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not
bar.com. If more than one identity of a given type is present in the
certificate (e.g. more than one dNSName name), a match in any one of
the set is considered acceptable.
If the hostname does not match the dNSName-based identity in the
certificate per the above check, user-oriented clients SHOULD either
notify the user (clients MAY give the user the opportunity to
Hodges, et al. Standards Track [Page 5]
RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
continue with the connection in any case) or terminate the connection
and indicate that the server's identity is suspect. Automated clients
SHOULD close the connection, returning and/or logging an error
indicating that the server's identity is suspect.
Beyond the server identity checks described in this section, clients
SHOULD be prepared to do further checking to ensure that the server
is authorized to provide the service it is observed to provide. The
client MAY need to make use of local policy information.
3.7. Refresh of Server Capabilities Information
The client MUST refresh any cached server capabilities information
(e.g. from the server's root DSE; see section 3.4 of [LDAPv3]) upon
TLS session establishment. This is necessary to protect against
active-intermediary attacks which may have altered any server
capabilities information retrieved prior to TLS establishment. The
server MAY advertise different capabilities after TLS establishment.
4. Closing a TLS Connection
4.1. Graceful Closure
Either the client or server MAY terminate the TLS connection on an
LDAP association by sending a TLS closure alert. This will leave the
LDAP association intact.
Before closing a TLS connection, the client MUST either wait for any
outstanding LDAP operations to complete, or explicitly abandon them
[LDAPv3].
After the initiator of a close has sent a closure alert, it MUST
discard any TLS messages until it has received an alert from the
other party. It will cease to send TLS Record Protocol PDUs, and
following the receipt of the alert, MAY send and receive LDAP PDUs.
The other party, if it receives a closure alert, MUST immediately
transmit a TLS closure alert. It will subsequently cease to send TLS
Record Protocol PDUs, and MAY send and receive LDAP PDUs.
4.2. Abrupt Closure
Either the client or server MAY abruptly close the entire LDAP
association and any TLS connection established on it by dropping the
underlying TCP connection. A server MAY beforehand send the client a
Notice of Disconnection [LDAPv3] in this case.
Hodges, et al. Standards Track [Page 6]
RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
5. Effects of TLS on a Client's Authorization Identity
This section describes the effects on a client's authorization
identity brought about by establishing TLS on an LDAP association.
The default effects are described first, and next the facilities for
client assertion of authorization identity are discussed including
error conditions. Lastly, the effects of closing the TLS connection
are described.
Authorization identities and related concepts are defined in
[AuthMeth].
5.1. TLS Connection Establishment Effects
5.1.1. Default Effects
Upon establishment of the TLS connection onto the LDAP association,
any previously established authentication and authorization
identities MUST remain in force, including anonymous state. This
holds even in the case where the server requests client
authentication via TLS -- e.g. requests the client to supply its
certificate during TLS negotiation (see [TLS]).
5.1.2. Client Assertion of Authorization Identity
A client MAY either implicitly request that its LDAP authorization
identity be derived from its authenticated TLS credentials or it MAY
explicitly provide an authorization identity and assert that it be
used in combination with its authenticated TLS credentials. The
former is known as an implicit assertion, and the latter as an
explicit assertion.
5.1.2.1. Implicit Assertion
An implicit authorization identity assertion is accomplished after
TLS establishment by invoking a Bind request of the SASL form using
the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL NOT include
the optional credentials octet string (found within the
SaslCredentials sequence in the Bind Request). The server will derive
the client's authorization identity from the authentication identity
supplied in the client's TLS credentials (typically a public key
certificate) according to local policy. The underlying mechanics of
how this is accomplished are implementation specific.
Hodges, et al. Standards Track [Page 7]
RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
5.1.2.2. Explicit Assertion
An explicit authorization identity assertion is accomplished after
TLS establishment by invoking a Bind request of the SASL form using
the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL include the
credentials octet string. This string MUST be constructed as
documented in section 9 of [AuthMeth].
5.1.2.3. Error Conditions
For either form of assertion, the server MUST verify that the
client's authentication identity as supplied in its TLS credentials
is permitted to be mapped to the asserted authorization identity. The
server MUST reject the Bind operation with an invalidCredentials
resultCode in the Bind response if the client is not so authorized.
Additionally, with either form of assertion, if a TLS session has not
been established between the client and server prior to making the
SASL EXTERNAL Bind request and there is no other external source of
authentication credentials (e.g. IP-level security [IPSEC]), or if,
during the process of establishing the TLS session, the server did
not request the client's authentication credentials, the SASL
EXTERNAL bind MUST fail with a result code of
inappropriateAuthentication.
After the above Bind operation failures, any client authentication
and authorization state of the LDAP association is lost, so the LDAP
association is in an anonymous state after the failure. TLS
connection state is unaffected, though a server MAY end the TLS
connection, via a TLS close_notify message, based on the Bind failure
(as it MAY at any time).
5.2. TLS Connection Closure Effects
Closure of the TLS connection MUST cause the LDAP association to move
to an anonymous authentication and authorization state regardless of
the state established over TLS and regardless of the authentication
and authorization state prior to TLS connection establishment.
6. Security Considerations
The goals of using the TLS protocol with LDAP are to ensure
connection confidentiality and integrity, and to optionally provide
for authentication. TLS expressly provides these capabilities, as
described in [TLS].
Hodges, et al. Standards Track [Page 8]
RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
All security gained via use of the Start TLS operation is gained by
the use of TLS itself. The Start TLS operation, on its own, does not
provide any additional security.
The use of TLS does not provide or ensure for confidentiality and/or
non-repudiation of the data housed by an LDAP-based directory server.
Nor does it secure the data from inspection by the server
administrators. Once established, TLS only provides for and ensures
confidentiality and integrity of the operations and data in transit
over the LDAP association, and only if the implementations on the
client and server support and negotiate it.
The level of security provided though the use of TLS depends directly
on both the quality of the TLS implementation used and the style of
usage of that implementation. Additionally, an active-intermediary
attacker can remove the Start TLS extended operation from the
supportedExtension attribute of the root DSE. Therefore, both parties
SHOULD independently ascertain and consent to the security level
achieved once TLS is established and before beginning use of the TLS
connection. For example, the security level of the TLS connection
might have been negotiated down to plaintext.
Clients SHOULD either warn the user when the security level achieved
does not provide confidentiality and/or integrity protection, or be
configurable to refuse to proceed without an acceptable level of
security.
Client and server implementors SHOULD take measures to ensure proper
protection of credentials and other confidential data where such
measures are not otherwise provided by the TLS implementation.
Server implementors SHOULD allow for server administrators to elect
whether and when connection confidentiality and/or integrity is
required, as well as elect whether and when client authentication via
TLS is required.
7. Acknowledgements
The authors thank Tim Howes, Paul Hoffman, John Kristian, Shirish
Rai, Jonathan Trostle, Harald Alvestrand, and Marcus Leech for their
contributions to this document.
Hodges, et al. Standards Track [Page 9]
RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
8. References
[AuthMeth] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
"Authentication Methods for LDAP", RFC 2829, May 2000.
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[LDAPv3] Wahl, M., Kille S. and T. Howes, "Lightweight
Directory Access Protocol (v3)", RFC 2251, December
1997.
[ReqsKeywords] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[TLS] Dierks, T. and C. Allen. "The TLS Protocol Version
1.0", RFC 2246, January 1999.
9. Authors' Addresses
Jeff Hodges
Oblix, Inc.
18922 Forge Drive
Cupertino, CA 95014
USA
Phone: +1-408-861-6656
EMail: JHodges@oblix.com
RL "Bob" Morgan
Computing and Communications
University of Washington
Seattle, WA
USA
Phone: +1-206-221-3307
EMail: rlmorgan@washington.edu
Mark Wahl
Sun Microsystems, Inc.
8911 Capital of Texas Hwy #4140
Austin TX 78759
USA
EMail: M.Wahl@innosoft.com
Hodges, et al. Standards Track [Page 10]
RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
10. Intellectual Property Rights Notices
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Hodges, et al. Standards Track [Page 11]
RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
11. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hodges, et al. Standards Track [Page 12]

339
doc/rfc/rfc3377.txt
View file

@ -1,339 +0,0 @@
Network Working Group J. Hodges
Request for Comments: 3377 Sun Microsystems Inc.
Category: Standards Track R. Morgan
University of Washington
September 2002
Lightweight Directory Access Protocol (v3):
Technical Specification
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 (2002). All Rights Reserved.
Abstract
This document specifies the set of RFCs comprising the Lightweight
Directory Access Protocol Version 3 (LDAPv3), and addresses the "IESG
Note" attached to RFCs 2251 through 2256.
1. Background and Motivation
The specification for the Lightweight Directory Access Protocol
version 3 (LDAPv3) nominally comprises eight RFCs which were issued
in two distinct subsets at separate times -- RFCs 2251 through 2256
first, then RFCs 2829 and 2830 following later.
RFC 2251 through 2256 do not mandate the implementation of any
satisfactory authentication mechanisms and hence were published with
an "IESG Note" discouraging implementation and deployment of LDAPv3
clients or servers implementing update functionality until a Proposed
Standard for mandatory authentication in LDAPv3 is published.
RFC 2829 was subsequently published in answer to the IESG Note.
The purpose of this document is to explicitly specify the set of RFCs
comprising LDAPv3, and formally address the IESG Note through
explicit inclusion of RFC 2829.
Hodges & Morgan Standards Track [Page 1]
RFC 3377 LDAPv3: Technical Specification September 2002
2. Specification of LDAPv3
The Lightweight Directory Access Protocol version 3 (LDAPv3) is
specified by this set of nine RFCs:
[RFC2251] Lightweight Directory Access Protocol (v3) [the
specification of the LDAP on-the-wire protocol]
[RFC2252] Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions
[RFC2253] Lightweight Directory Access Protocol (v3): UTF-8
String Representation of Distinguished Names
[RFC2254] The String Representation of LDAP Search Filters
[RFC2255] The LDAP URL Format
[RFC2256] A Summary of the X.500(96) User Schema for use with
LDAPv3
[RFC2829] Authentication Methods for LDAP
[RFC2830] Lightweight Directory Access Protocol (v3): Extension
for Transport Layer Security
And, this document (RFC3377).
The term "LDAPv3" is often used informally to refer to the protocol
specified by the above set of RFCs, or subsets thereof. However, the
LDAPv3 protocol suite, as defined here, should be formally identified
in other documents by a normative reference to this document.
3. Addressing the "IESG Note" in RFCs 2251 through 2256
The IESG approved publishing RFCs 2251 through 2256 with an attendant
IESG Note included in each document. The Note begins with:
This document describes a directory access protocol that provides
both read and update access. Update access requires secure
authentication, but this document does not mandate implementation
of any satisfactory authentication mechanisms.
Hodges & Morgan Standards Track [Page 2]
RFC 3377 LDAPv3: Technical Specification September 2002
The Note ends with this statement:
Implementors are hereby discouraged from deploying LDAPv3 clients
or servers which implement the update functionality, until a
Proposed Standard for mandatory authentication in LDAPv3 has been
approved and published as an RFC.
[RFC2829] is expressly the "Proposed Standard for mandatory
authentication in LDAPv3" called for in the Note. Thus, the IESG
Note in [RFC2251], [RFC2252], [RFC2253], [RFC2254], [RFC2255], and
[RFC2256] is addressed.
4. Security Considerations
This document does not directly discuss security, although the
context of the aforementioned IESG Note is security related, as is
the manner in which it is addressed.
Please refer to the referenced documents, especially [RFC2829],
[RFC2251], and [RFC2830], for further information concerning LDAPv3
security.
5. Acknowledgements
The authors thank Patrik Faltstrom, Leslie Daigle, Thomas Narten, and
Kurt Zeilenga for their contributions to this document.
6. References
[RFC2251] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
[RFC2253] Kille, S., Wahl, M. and T. Howes, "Lightweight Directory
Access Protocol (v3): UTF-8 String Representation of
Distinguished Names", RFC 2253, December 1997.
[RFC2254] Howes, T., "The String Representation of LDAP Search
Filters", RFC 2254, December 1997.
[RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
December 1997.
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997.
Hodges & Morgan Standards Track [Page 3]
RFC 3377 LDAPv3: Technical Specification September 2002
[RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
"Authentication Methods for LDAP", RFC 2829, May 2000.
[RFC2830] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory
Access Protocol (v3): Extension for Transport Layer
Security", RFC 2830, May 2000.
7. Intellectual Property Rights Notices
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Hodges & Morgan Standards Track [Page 4]
RFC 3377 LDAPv3: Technical Specification September 2002
8. Authors' Addresses
Jeff Hodges
Sun Microsystems, Inc.
901 San Antonio Road, USCA22-212
Palo Alto, CA 94303
USA
Phone: +1-408-276-5467
EMail: Jeff.Hodges@sun.com
RL "Bob" Morgan
Computing and Communications
University of Washington
Seattle, WA
USA
Phone: +1-206-221-3307
EMail: rlmorgan@washington.edu
Hodges & Morgan Standards Track [Page 5]
RFC 3377 LDAPv3: Technical Specification September 2002
9. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hodges & Morgan Standards Track [Page 6]

1291
doc/rfc/rfc3383.txt
View file

File diff suppressed because it is too large Load diff

283
doc/rfc/rfc3674.txt
View file

@ -1,283 +0,0 @@
Network Working Group K. Zeilenga
Request for Comments: 3674 OpenLDAP Foundation
Category: Standards Track December 2003
Feature Discovery in Lightweight Directory Access Protocol (LDAP)
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 (2003). All Rights Reserved.
Abstract
The Lightweight Directory Access Protocol (LDAP) is an extensible
protocol with numerous elective features. This document introduces a
general mechanism for discovery of elective features and extensions
which cannot be discovered using existing mechanisms.
1. Background and Intended Use
The Lightweight Directory Access Protocol (LDAP) [RFC3377] is an
extensible protocol with numerous elective features. LDAP provides
mechanisms for a client to discover supported protocol versions,
controls, extended operations, Simple Authentication and Security
Layer (SASL) mechanisms, and subschema information. However, these
mechanisms are not designed to support general feature discovery.
This document describes a simple, general-purpose mechanism which
clients may use to discover the set of elective features supported by
a server. For example, this mechanism could be used by a client to
discover whether or not the server supports requests for all
operational attributes, e.g., "+" [RFC3673]. As another example,
this mechanism could be used to discover absolute true, e.g., "(&)"
and false, e.g., "(|)", search filters [T-F] support.
This document extends the LDAP Protocol Mechanism registry [RFC3383]
to support registration of values of the supportedFeatures attribute.
This registry is managed by the Internet Assigned Numbers Authority
(IANA).
Zeilenga Standards Track [Page 1]
RFC 3674 Feature Discovery in LDAP December 2003
Schema definitions are provided using LDAP description formats
[RFC2252]. Definitions provided here are formatted (line wrapped)
for readability.
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. Discovery of supported features
Each elective feature whose support may be discovered SHALL be
identified by an Object Identifier (OID). A server advertises its
support for a given feature by providing the OID associated with the
feature as a value of the 'supportedFeatures' attribute held in the
root DSE. A client may examine the values of this attribute to
determine if a particular feature is supported by the server. A
client MUST ignore values it doesn't recognize as they refer to
elective features it doesn't implement.
Features associated with Standard Track protocol mechanisms MUST be
registered. Features associated with other protocol mechanisms
SHOULD be registered. Procedures for registering protocol mechanisms
are described in BCP 64 [RFC3383]. The word "Feature" should be
placed in the usage field of the submitted LDAP Protocol Mechanism
template.
The 'supportedFeatures' attribute type is described as follows:
( 1.3.6.1.4.1.4203.1.3.5
NAME 'supportedFeatures'
DESC 'features supported by the server'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )
Servers MUST be capable of recognizing this attribute type by the
name 'supportedFeatures'. Servers MAY recognize the attribute type
by other names.
3. Security Considerations
As rogue clients can discover features of a server by other means
(such as by trial and error), this feature discovery mechanism is not
believed to introduce any new security risk to LDAP.
Zeilenga Standards Track [Page 2]
RFC 3674 Feature Discovery in LDAP December 2003
4. IANA Considerations
4.1. Registration of Features as Protocol Mechanisms
Future specifications detailing LDAP features are to register each
feature as a LDAP Protocol Mechanism per guidance given in BCP 64
[RFC3383]. A usage of "Feature" in a Protocol Mechanism registration
template indicates that the value to be registered is associated with
an LDAP feature.
4.2. Registration of the supportedFeatures descriptor
The IANA has registered the LDAP 'supportedFeatures' descriptor. The
following registration template is suggested:
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): supportedFeatures
Object Identifier: 1.3.6.1.4.1.4203.1.3.5
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: Attribute Type
Specification: RFC 3674
Author/Change Controller: IESG
This OID was assigned [ASSIGN] by OpenLDAP Foundation under its IANA
assigned private enterprise allocation [PRIVATE] for use in this
specification.
5. Acknowledgment
This document is based upon input from the IETF LDAPEXT working
group.
6. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
Zeilenga Standards Track [Page 3]
RFC 3674 Feature Discovery in LDAP December 2003
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
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.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority
(IANA) Considerations for Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
7.2. Informative References
[RFC3673] Zeilenga, K., "Lightweight Directory Access Protocol
version 3 (LDAPv3): All Operational Attributes", RFC
3673, December 2003.
[T-F] Zeilenga, K., "LDAP True/False Filters", Work in
Progress.
[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.
8. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
EMail: Kurt@OpenLDAP.org
Zeilenga Standards Track [Page 4]
RFC 3674 Feature Discovery in LDAP December 2003
9. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zeilenga Standards Track [Page 5]

451
doc/rfc/rfc3771.txt
View file

@ -1,451 +0,0 @@
Network Working Group R. Harrison
Request for Comments: 3771 Novell, Inc.
Updates: 2251 K. Zeilenga
Category: Standards Track OpenLDAP Foundation
April 2004
The Lightweight Directory Access Protocol (LDAP)
Intermediate Response Message
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 (2004). All Rights Reserved.
Abstract
This document defines and describes the IntermediateResponse message,
a general mechanism for defining single-request/multiple-response
operations in Lightweight Directory Access Protocol (LDAP). The
IntermediateResponse message is defined in such a way that the
protocol behavior of existing LDAP operations is maintained. This
message is intended to be used in conjunction with the LDAP
ExtendedRequest and ExtendedResponse to define new single-
request/multiple-response operations or in conjunction with a control
when extending existing LDAP operations in a way that requires them
to return intermediate response information.
Harrison & Zeilenga Standards Track [Page 1]
RFC 3771 LDAP Intermediate Response April 2004
1. Introduction
The Lightweight Directory Access Protocol (LDAP), version 3 [RFC3377]
is an extensible protocol. Extended operations ([RFC2251] Section
4.12) are defined to allow for the addition of operations to LDAP,
without requiring revisions of the protocol. Similarly, controls
([RFC2251] Section 4.1.12) are defined to extend or modify the
behavior of existing LDAP operations.
LDAP is a client-request/server-response based protocol. With the
exception of the search operation, the entire response to an
operation request is returned in a single protocol data unit (i.e.,
LDAP message). While this single-request/single-response paradigm is
sufficient for many operations (including all but one of those
currently defined by [RFC3377]), both intuition and practical
experience validate the notion that it is insufficient for others.
For example, the LDAP delete operation could be extended via a
subtree control to mean that an entire subtree is to be deleted. A
subtree delete operation needs to return continuation references
based upon subordinate knowledge information contained in the server
so that the client can complete the operation. Returning references
as they are found, instead of with the final result, allows the
client to perform the operation more efficiently because it does not
have to wait for the final result to get this continuation reference
information.
Similarly, an engineer might choose to design the subtree delete
operation as an extended operation of its own rather than using a
subtree control in conjunction with the delete operation. Once
again, the same continuation reference information is needed by the
client to complete the operation, and sending the continuation
references as they are found would allow the client to perform the
operation more efficiently.
Operations that are completed in stages or that progress through
various states as they are completed might want to send intermediate
responses to the client, thereby informing it of the status of the
operation. For example, an LDAP implementation might define an
extended operation to create a new replica of an administrative area
on a server, and the operation is completed in three stages: (1)
begin creation of replica, (2) send replica data to server, (3)
replica creation complete. Intermediate messages might be sent from
the server to the client at the beginning of each stage with the
final response for the extended operation being sent after stage (3)
is complete.
Harrison & Zeilenga Standards Track [Page 2]
RFC 3771 LDAP Intermediate Response April 2004
As LDAP [RFC3377] is currently defined, there is no general LDAP
message type that can be used to return intermediate results. A
single, reusable LDAP message for carrying intermediate response
information is desired to avoid repeated modification of the
protocol. Although the ExtendedResponse message is defined in LDAP,
it is defined to be the one and only response message to an
ExtendedRequest message ([RFC2251] Section 4.12), for unsolicited
notifications ([RFC2251] Section 4.4), and to return intermediate
responses for the search operation ([RFC3377] Section 4.5.2, also see
Section 5 below). The adaptation of ExtendedResponse as a general
intermediate response mechanism would be problematic. In particular,
existing APIs would likely have to be redesigned. It is believed
(based upon operational experience) that the addition of a new
message to carry intermediate result information is easier to
implement and is less likely to cause interoperability problems with
existing deployed implementations.
This document defines and describes the LDAP IntermediateResponse
message. This message is intended to be used in conjunction with
ExtendedRequest and ExtendedResponse to define new single-
request/multiple-response operations or in conjunction with a control
when extending existing LDAP operations in a way that requires them
to return intermediate response information.
It is intended that the definitions and descriptions of extended
operations and controls using the IntermediateResponse message will
define the circumstances in which an IntermediateResponse message can
be sent by a server and the associated meaning of the
IntermediateResponse message sent in a particular circumstance.
Similarly, it is intended that clients will explicitly solicit
IntermediateResponse messages by issuing operations that specifically
call for their return.
The LDAP Content Sync Operation [ZEILENGA] demonstrates one use of
LDAP Intermediate Response messages.
2. 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 [RFC2119].
The term "request control" is used to describe a control that is
included in an LDAP request message sent from an LDAP client to an
LDAP server.
Harrison & Zeilenga Standards Track [Page 3]
RFC 3771 LDAP Intermediate Response April 2004
3. The IntermediateResponse Message
This document extends the protocolOp CHOICE of LDAPMessage ([RFC2251]
Section 4.1.1) to include the field:
intermediateResponse IntermediateResponse
where IntermediateResponse is defined as:
IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
responseName [0] LDAPOID OPTIONAL,
responseValue [1] OCTET STRING OPTIONAL }
IntermediateResponse messages SHALL NOT be returned to the client
unless the client issues a request that specifically solicits their
return. This document defines two forms of solicitation: extended
operation and request control.
Although the responseName and responseValue are optional in some
circumstances, IntermediateResponse messages usually have a
predefined responseName and a responseValue. The value of the
responseName (if present), the syntax of the responseValue (if
present) and the semantics associated with a particular
IntermediateResponse message MUST be specified in documents
describing the extended operation or request control that uses them.
Sections 3.1 and 3.2 describe additional requirements for the
inclusion of responseName and responseValue in IntermediateResponse
messages.
3.1. Usage with LDAP ExtendedRequest and ExtendedResponse
A single-request/multiple-response operation may be defined using a
single ExtendedRequest message to solicit zero or more
IntermediateResponse messages, of one or more kinds, followed by an
ExtendedResponse message.
An extended operation that defines the return of multiple kinds of
IntermediateResponse messages MUST provide and document a mechanism
for the client to distinguish the kind of IntermediateResponse
message being sent. This SHALL be accomplished by using different
responseName values for each type of IntermediateResponse message
associated with the extended operation or by including identifying
information in the responseValue of each type of IntermediateResponse
message associated with the extended operation.
Harrison & Zeilenga Standards Track [Page 4]
RFC 3771 LDAP Intermediate Response April 2004
3.2. Usage with LDAP Request Controls
Any LDAP operation may be extended by the addition of one or more
controls ([RFC2251] Section 4.1.12). A control's semantics may
include the return of zero or more IntermediateResponse messages
prior to returning the final result code for the operation. One or
more kinds of IntermediateResponse messages may be sent in response
to a request control.
All IntermediateResponse messages associated with request controls
SHALL include a responseName. This requirement ensures that the
client can correctly identify the source of IntermediateResponse
messages when:
a) two or more controls using IntermediateResponse messages are
included in a request for any LDAP operation or
b) one or more controls using IntermediateResponse messages are
included in a request with an LDAP extended operation that uses
IntermediateResponse messages.
A request control that defines the return of multiple kinds of
IntermediateResponse messages MUST provide and document a mechanism
for the client to distinguish the kind of IntermediateResponse
message being sent. This SHALL be accomplished by using different
responseName values for each type of IntermediateResponse message
associated with the request control or by including identifying
information in the responseValue of each type of IntermediateResponse
message associated with the request control.
4. Advertising Support for IntermediateResponse Messages
Because IntermediateResponse messages are associated with extended
operations or controls and LDAP provides a means for advertising the
extended operations and controls supported by a server (using the
supportedExtension ([RFC2252] Section 5.2.3) and supportedControl
([RFC2252] Section 5.2.4) attributes of the root DSE), there is no
need for a separate means of advertising support for intermediate
response messages.
5. Use of IntermediateResponse and ExtendedResponse with Search
It is noted that ExtendedResponse messages may be sent in response to
LDAP search operations with controls ([RFC2251] Section 4.5.2). This
use of ExtendedResponse messages SHOULD be viewed as deprecated, in
favor of use of the IntermediateResponse messages.
Harrison & Zeilenga Standards Track [Page 5]
RFC 3771 LDAP Intermediate Response April 2004
6. Security Considerations
This document describes an enhancement to LDAP. All security
considerations of [RFC3377] apply to this document; however, it does
not introduce any new security considerations to LDAP.
Security considerations specific to each extension using this
protocol mechanism shall be discussed in the technical specification
detailing the extension.
7. IANA Considerations
Registration of the following value has been completed [RFC3383].
7.1. LDAP Message Type
The IANA has registered an LDAP Message Type (25) to identify the
LDAP IntermediateResponse message as defined in section 3 of this
document.
The following registration template is suggested:
Subject: Request for LDAP Message Type Registration
Person & email address to contact for further information:
Roger Harrison <roger_harrison@novell.com>
Specification: RFC3771
Author/Change Controller: IESG
Comments: Identifies the LDAP IntermediateResponse Message
8. Acknowledgments
The authors would like to acknowledge the members of the IETF LDAP
Extensions (ldapext) working group mail list who responded to the
suggestion that a multiple-response paradigm might be useful for LDAP
extended requests. Special thanks to two individuals: David Wilbur
who first introduced the idea on the working group list, and Thomas
Salter, who succinctly summarized the group's discussion.
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.
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
Harrison & Zeilenga Standards Track [Page 6]
RFC 3771 LDAP Intermediate Response April 2004
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
9.2. Informative References
[ZEILENGA] Zeilenga, K., "LDAP Content Synchronization Operation",
Work in Progress, February 2004.
10. Authors' Addresses
Roger Harrison
Novell, Inc.
1800 S. Novell Place
Provo, UT 84606
Phone: +1 801 861 2642
EMail: roger_harrison@novell.com
Kurt D. Zeilenga
OpenLDAP Foundation
EMail: Kurt@OpenLDAP.org
Harrison & Zeilenga Standards Track [Page 7]
RFC 3771 LDAP Intermediate Response April 2004
11. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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 currently provided by the
Internet Society.
Harrison & Zeilenga Standards Track [Page 8]

395
doc/rfc/rfc4510.txt Normal file
View 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
doc/rfc/rfc4511.txt Normal file
View file

File diff suppressed because it is too large Load diff

2915
doc/rfc/rfc4512.txt Normal file
View file

File diff suppressed because it is too large Load diff

1907
doc/rfc/rfc4513.txt Normal file
View file

File diff suppressed because it is too large Load diff

843
doc/rfc/rfc4514.txt Normal file
View 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]

659
doc/drafts/draft-ietf-ldapbis-filter-xx.txt → doc/rfc/rfc4515.txt
View file

@ -1,115 +1,80 @@
Network Working Group M. Smith, Editor
Request for Comments: DRAFT Pearl Crescent, LLC
Obsoletes: RFC 2254 T. Howes
Expires: 16 May 2005 Opsware, Inc.
16 November 2004
LDAP: String Representation of Search Filters
<draft-ietf-ldapbis-filter-09.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she become
aware will be disclosed, in accordance with RFC 3668.
This document is intended to be published as a Standards Track RFC,
replacing RFC 2254. Distribution of this memo is unlimited.
Technical discussion of this document will take place on the IETF
LDAP (v3) Revision (ldapbis) Working Group mailing list
<ietf-ldapbis@openldap.org>. Please send editorial comments directly
to the editor <mcs@pearlcrescent.com>.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2004). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Smith & Howes Intended Category: Standards Track [Page 1]
Network Working Group M. Smith, Ed.
Request for Comments: 4515 Pearl Crescent, LLC
Obsoletes: 2254 T. Howes
Category: Standards Track Opsware, Inc.
June 2006
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
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
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 [LDAPURL] and
in other applications.
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
Status of this Memo............................................1
Abstract.......................................................2
Table of Contents..............................................2
1. Introduction...................................................2
2. LDAP Search Filter Definition..................................3
3. String Search Filter Definition................................4
4. Examples.......................................................6
5. Security Considerations........................................7
6. IANA Considerations............................................7
7. Normative References...........................................7
8. Informative References.........................................8
9. Acknowledgments................................................8
10. Authors' Addresses.............................................9
11. Appendix A: Changes Since RFC 2254.............................9
11.1. Technical Changes...........................................9
11.2. Editorial Changes...........................................10
12. Appendix B: Changes Since Previous Document Revision...........11
12.1. Technical Changes...........................................11
12.2. Editorial Changes...........................................12
Intellectual Property Rights...................................12
Full Copyright.................................................13
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) [Roadmap] defines a
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
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.
[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
[Roadmap] which obsoletes the previously defined LDAP technical
[RFC4510], which obsoletes the previously defined LDAP technical
specification, RFC 3377, in its entirety.
Smith & Howes Intended Category: Standards Track [Page 2]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
This document replaces RFC 2254. Changes to RFC 2254 are summarized
in Appendix A.
@ -119,7 +84,7 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
2. LDAP Search Filter Definition
An LDAP search filter is defined in Section 4.5.1 of [Protocol] as
An LDAP search filter is defined in Section 4.5.1 of [RFC4511] as
follows:
Filter ::= CHOICE {
@ -142,6 +107,15 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
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 }
@ -154,18 +128,10 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
AttributeDescription ::= LDAPString
-- Constrained to <attributedescription>
-- [Models]
-- [RFC4512]
AttributeValue ::= OCTET STRING
Smith & Howes Intended Category: Standards Track [Page 3]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
MatchingRuleId ::= LDAPString
AssertionValue ::= OCTET STRING
@ -173,20 +139,20 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [Unicode] characters
The AttributeDescription, as defined in [Protocol], is a string
The AttributeDescription, as defined in [RFC4511], is a string
representation of the attribute description that is discussed in
[Models]. The AttributeValue and AssertionValue OCTET STRING have
the form defined in [Syntaxes]. The Filter is encoded for
[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 [Protocol].
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
[RFC2234]. The productions used that are not defined here are
defined in section 1.4 (Common ABNF Productions) of [Models] unless
[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
@ -198,6 +164,14 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
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
@ -213,20 +187,12 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
final = assertionvalue
attr = attributedescription
; The attributedescription rule is defined in
; Section 2.5 of [Models].
Smith & Howes Intended Category: Standards Track [Page 4]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
; 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 [Protocol].
; from Section 4.1.6 of [RFC4511].
valueencoding = 0*(normal / escaped)
normal = UTF1SUBSET / UTFMB
escaped = ESC HEX HEX
@ -240,7 +206,6 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
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.
@ -252,10 +217,21 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
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,
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
@ -269,18 +245,10 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
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
Smith & Howes Intended Category: Standards Track [Page 5]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
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).
search filter is a string of UTF-8-encoded Unicode characters).
4. Examples
@ -307,9 +275,18 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
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 matching rule identified by the OID "2.4.6.8.10" should
be used when making comparisons, and that the attributes of an
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").
@ -326,14 +303,6 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
supporting the matching rule contained in the DN should also be
considered.
Smith & Howes Intended Category: Standards Track [Page 6]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
The following examples illustrate the use of the escaping mechanism.
(o=Parens R Us \28for all your parenthetical needs\29)
@ -344,91 +313,100 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
(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
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
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).
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
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
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 [Protocol]
and [AuthMeth] for more information.
Please refer to the Security Considerations sections of [RFC4511] and
[RFC4513] for more information.
6. IANA Considerations
6. Normative References
This document has no actions for IANA.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7. Normative References
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms",
[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 & Howes Intended Category: Standards Track [Page 7]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
Smith and Howes Standards Track [Page 7]
RFC 4515 LDAP: String Representation of Search Filters June 2006
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
7. Informative References
[Models] Zeilenga, K. (editor), "LDAP: Directory Information Models",
draft-ietf-ldapbis-models-xx.txt, a work in progress.
[RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory
Access Protocol (LDAP): Uniform Resource Locator", RFC
4516, June 2006.
[Protocol] draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[X.690] Specification of ASN.1 encoding rules: Basic, Canonical,
and Distinguished Encoding Rules, ITU-T Recommendation
X.690, 1994.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 3629, November 2003.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
[Syntaxes] Dally, K. (editor), "LDAP: Syntaxes",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[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."
8. Informative References
[LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
draft-ietf-ldapbis-url-xx.txt, a work in progress.
[X.690] Specification of ASN.1 encoding rules: Basic, Canonical, and
Distinguished Encoding Rules, ITU-T Recommendation X.690,
1994.
9. Acknowledgments
8. Acknowledgements
This document replaces RFC 2254 by Tim Howes. RFC 2254 was a product
of the IETF ASID Working Group.
@ -441,77 +419,75 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
Smith & Howes Intended Category: Standards Track [Page 8]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
10. Authors' Addresses
Mark Smith, Editor
Pearl Crescent, LLC
447 Marlpool Dr.
Saline, MI 48176
USA
+1 734 944-2856
mcs@pearlcrescent.com
Tim Howes
Opsware, Inc.
599 N. Mathilda Ave.
Sunnyvale, CA 94085
USA
+1 408 744-7509
howes@opsware.com
11. Appendix A: Changes Since RFC 2254
11.1. Technical Changes
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
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 [Models].
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 [Syntaxes].
"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 [Models] and [Protocol]
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.
Smith & Howes Intended Category: Standards Track [Page 9]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
Introduced the "valueencoding" and associated "normal" and "escaped"
rules to reduce the dependence on descriptive text. The "normal"
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."
11.2. Editorial Changes
A.2. Editorial Changes
Changed document title to include "LDAP:" prefix.
@ -521,24 +497,30 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
Header and "Authors' Addresses" sections: added Mark Smith as the
document editor and updated affiliation and contact information.
"Table of Contents", "IANA Considerations", and "Intellectual
Property Rights" sections: added.
"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 [Roadmap]
document.
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 [Protocol].
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 [Protocol] section 4.1.6 (special handling is required for some
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.
@ -550,105 +532,111 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
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
Smith & Howes Intended Category: Standards Track [Page 10]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
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 [Protocol] and
[AuthMeth].
"Security Considerations" section: added references to [RFC4511] and
[RFC4513].
"Normative References" section: renamed from "References" per new RFC
guidelines. Changed from [1] style to [Protocol] style throughout the
document. Added entries for [Unicode], [RFC2119], [AuthMeth],
[Models], and [Roadmap] and updated the UTF-8 reference. Replaced
RFC 822 reference with a reference to RFC 2234.
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 [LDAPURL].
section. Added a reference to [RFC4516].
"Acknowledgments" section: added.
"Acknowledgements" section: added.
"Appendix A: Changes Since RFC 2254" section: added.
"Appendix B: Changes Since Previous Document Revision" section:
added.
Surrounded the names of all ABNF productions with "<" and ">" where
they are used in descriptive text.
Replaced all occurrences of "LDAPv3" with "LDAP."
12. Appendix B: Changes Since Previous Document Revision
Smith and Howes Standards Track [Page 10]
RFC 4515 LDAP: String Representation of Search Filters June 2006
This appendix lists all changes relative to the previously published
revision, draft-ietf-ldapbis-filter-08.txt. Note that when
appropriate these changes are also included in Appendix A, but are
also included here for the benefit of the people who have already
reviewed draft-ietf-ldapbis-filter-08.txt. This section will be
removed before this document is published as an RFC.
12.1. Technical Changes
Removed the third option from the "extensible" production that
allowed creation of a MatchingRuleAssertion that only had a
matchValue (disallowed By [Protocol]). Added "(" and ")" around the
components of the <extensible> subproductions for clarity.
Smith & Howes Intended Category: Standards Track [Page 11]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
12.2. Editorial Changes
"Introduction" section: referenced [Roadmap] upon first use of LDAP
and expanded the paragraph that begins "This document is an integral
part of the LDAP technical specification..." to match the text used
in [Protocol].
"LDAP Search Filter Definition" section: reworded the last paragraph
for clarity.
"Examples" section: 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.
References: added [LDAPURL] and moved [X.690] to "Informative
References."
"Acknowledgements" section: added the sentence "RFC 2254 was a
product of the IETF ASID Working Group."
Changed these two sections to unnumbered ones: "Intellectual Property
Rights" and "Full Copyright."
Surrounded the names of all ABNF productions with "<" and ">" where
they are used in descriptive text.
Replaced all occurrences of "LDAPv3" with "LDAP."
Authors' Addresses
Intellectual Property Rights
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
@ -662,14 +650,6 @@ Intellectual Property Rights
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
Smith & Howes Intended Category: Standards Track [Page 12]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
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.
@ -680,22 +660,10 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Full Copyright
Acknowledgement
Copyright (C) The Internet Society (2004). 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.
This Internet Draft expires on 16 May 2005.
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
@ -703,22 +671,5 @@ This Internet Draft expires on 16 May 2005.
Smith & Howes Intended Category: Standards Track [Page 13]
Smith and Howes Standards Track [Page 12]

843
doc/rfc/rfc4516.txt Normal file
View 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]

1934
doc/drafts/draft-ietf-ldapbis-syntaxes-xx.txt → doc/rfc/rfc4517.txt
View file

File diff suppressed because it is too large Load diff

787
doc/rfc/rfc4518.txt Normal file
View 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]

1692
doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt → doc/rfc/rfc4519.txt
View file

File diff suppressed because it is too large Load diff

1067
doc/rfc/rfc4520.txt Normal file
View file

File diff suppressed because it is too large Load diff

899
doc/rfc/rfc4521.txt Normal file
View 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]

464
doc/drafts/draft-legg-ldap-binary-xx.txt → doc/rfc/rfc4522.txt
View file

@ -4,45 +4,25 @@
INTERNET-DRAFT S. Legg
draft-legg-ldap-binary-04.txt eB2Bcom
Intended Category: Standards Track 30 January 2006
Network Working Group S. Legg
Request for Comments: 4522 eB2Bcom
Category: Standards Track June 2006
Lightweight Directory Access Protocol (LDAP):
The Binary Encoding Option
Copyright (C) The Internet Society (2006).
Status of This Memo
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.
By submitting this Internet-draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Copyright Notice
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Technical discussion of this document should take place on the IETF
LDAP Revision Working Group (LDAPbis) mailing list
<ietf-ldapbis@openldap.org>. Please send editorial comments directly
to the editor <steven.legg@eb2bcom.com>.
This Internet-Draft expires on 30 July 2006.
Copyright (C) The Internet Society (2006).
Abstract
@ -52,108 +32,55 @@ Abstract
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
Legg Expires 30 July 2006 [Page 1]
INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
document defines an attribute option, the binary option, which can be
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.
Legg Expires 30 July 2006 [Page 2]
INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The binary Option. . . . . . . . . . . . . . . . . . . . . . . 4
4. Syntaxes Requiring Binary Transfer . . . . . . . . . . . . . . 4
5. Attributes Returned in a Search. . . . . . . . . . . . . . . . 5
6. All User Attributes. . . . . . . . . . . . . . . . . . . . . . 6
7. Conflicting Requests . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References. . . . . . . . . . . . . . . . . . 7
10.2. Informative References. . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8
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 [ROADMAP] has a defined syntax (i.e., data type)
(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 [SYNTAX] specifies how attribute or
assertion values [MODELS] conforming to the syntax are normally
represented when transferred in LDAP operations [PROT]. This
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 [MODELS] 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.
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 [ROADMAP] has obsoleted the previously
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
@ -161,48 +88,48 @@ Table of Contents
the known inconsistencies.
This document reintroduces the binary option for use with certain
attribute syntaxes, such as certificate syntax [PKI], which
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 which do not require
Legg Expires 30 July 2006 [Page 3]
INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
its use. Unless addressed in a future specification, this use is to
be avoided.
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
"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
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.
Where the binary option is present in an attribute description the
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 [SYNTAX] for the attribute's syntax). Note that it is
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 [PROT], 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.
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 [MODELS] so the presence of
the binary option does not specify an attribute subtype. An
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
@ -211,29 +138,21 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
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 [SYNTAX], or the BER encoding of values
of that type is not supported.
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 protocol; servers store
any particular attribute value in a format of their choosing.
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
Legg Expires 30 July 2006 [Page 4]
INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
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
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 [PKI] are examples of syntaxes with a binary
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
@ -241,14 +160,26 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
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 [PROT] 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 [MODELS].
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
@ -259,42 +190,44 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
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
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
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
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.
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
Legg Expires 30 July 2006 [Page 5]
INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
returned at most once.
6. All User Attributes
If the list of attributes in a search request is empty, or contains
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.
@ -308,10 +241,10 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
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 not present in all
these attribute descriptions, nor absent in all these attribute
descriptions, then the effect of the request with respect to binary
transfer is implementation defined.
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
@ -322,9 +255,9 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
9. IANA Considerations
The Internet Assigned Numbers Authority (IANA) is requested to update
the LDAP attribute description option registry [BCP64] as indicated
by the following template:
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
@ -332,18 +265,8 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
Family of Options: NO
Person & email address to contact for further information:
Steven Legg <steven.legg@eb2bcom.com>
Legg Expires 30 July 2006 [Page 6]
INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
Specification: RFC XXXX
Specification: RFC 4522
Author/Change Controller: IESG
Comments: The existing registration for "binary"
should be updated to refer to RFC XXXX.
10. References
@ -352,32 +275,37 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
[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 3383, September 2002.
Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map",
draft-ietf-ldapbis-roadmap-xx.txt, a work in progress,
February 2005.
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC RFC 4510,
June 2006.
[MODELS] Zeilenga, K., "LDAP: Directory Information Models",
draft-ietf-ldapbis-models-xx.txt, a work in progress,
February 2005.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006.
[PROT] Sermersheim, J., "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress,
October 2005.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June
2006.
[SYNTAX] Legg, S., "Lightweight Directory Access Protocol (LDAP):
Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress,
June 2005.
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
(LDAP): Syntaxes and Matching Rules", RFC 4517, June
2006.
[PKI] Zeilenga, Kurt D., "Lightweight Directory Access Protocol
(LDAP) schema definitions for X.509 Certificates",
draft-zeilenga-ldap-x509-xx.txt, a work in progress, July
2005.
[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:
@ -387,15 +315,7 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
10.2. Informative References
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Legg Expires 30 July 2006 [Page 7]
INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
[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
@ -404,7 +324,21 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
[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
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
@ -416,9 +350,52 @@ Author's Address
AUSTRALIA
Phone: +61 3 9896 7830
Fax: +61 3 9896 7801
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).
@ -444,14 +421,6 @@ Intellectual Property
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
Legg Expires 30 July 2006 [Page 8]
INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
@ -467,6 +436,10 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
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).
@ -474,34 +447,5 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
Legg Expires 30 July 2006 [Page 9]
Legg Standards Track [Page 8]

1347
doc/rfc/rfc4523.txt Normal file
View file

File diff suppressed because it is too large Load diff

1403
doc/rfc/rfc4524.txt Normal file
View file

File diff suppressed because it is too large Load diff

339
doc/rfc/rfc4525.txt Normal file
View 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
doc/rfc/rfc4526.txt Normal file
View 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
doc/rfc/rfc4527.txt Normal file
View 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
doc/rfc/rfc4528.txt Normal file
View 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
doc/rfc/rfc4529.txt Normal file
View 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
doc/rfc/rfc4530.txt Normal file
View 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
doc/rfc/rfc4531.txt Normal file
View 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
doc/rfc/rfc4532.txt Normal file
View 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
doc/rfc/rfc4533.txt Normal file
View file

File diff suppressed because it is too large Load diff