[Pkg-openldap-devel] r844 - in openldap/vendor/openldap-release: . build clients/tools doc doc/drafts doc/guide/admin doc/man/man1 doc/man/man5 doc/man/man8 doc/rfc include libraries/liblber libraries/libldap libraries/libldap_r libraries/liblutil servers/slapd servers/slapd/back-bdb servers/slapd/back-ldap servers/slapd/back-ldbm servers/slapd/back-meta servers/slapd/back-perl servers/slapd/back-relay servers/slapd/back-sql servers/slapd/overlays servers/slapd/schema servers/slurpd
Matthijs Mohlmann
matthijs at alioth.debian.org
Sat Sep 15 10:38:53 UTC 2007
Author: matthijs
Date: 2007-09-15 10:38:52 +0000 (Sat, 15 Sep 2007)
New Revision: 844
Added:
openldap/vendor/openldap-release/doc/drafts/
openldap/vendor/openldap-release/doc/drafts/README
openldap/vendor/openldap-release/doc/drafts/draft-behera-ldap-password-policy-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-chu-ldap-csn-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-bcp64-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-dn-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-filter-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-models-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-protocol-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-roadmap-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-strprep-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-syntaxes-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-url-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-acl-model-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-ldap-c-api-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-ldapv3-dupent-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-ldapv3-vlv-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-locate-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-joslin-config-schema-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-lachman-laser-ldap-mail-routing-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-acm-admin-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-acm-bac-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-admin-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-binary-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-transfer-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-sermersheim-ldap-chaining-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-sermersheim-ldap-csn-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-sermersheim-ldap-distproc-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-sermersheim-ldap-subordinate-scope-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-adlist-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-assert-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-authzid-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-cosine-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-dontusecopy-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-incr.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-managedit-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-noop-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-readentry-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-t-f-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-turn-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-txn-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-uuid-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-x509-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldup-sync-xx.txt
openldap/vendor/openldap-release/doc/rfc/
openldap/vendor/openldap-release/doc/rfc/INDEX
openldap/vendor/openldap-release/doc/rfc/rfc1274.txt
openldap/vendor/openldap-release/doc/rfc/rfc2079.txt
openldap/vendor/openldap-release/doc/rfc/rfc2247.txt
openldap/vendor/openldap-release/doc/rfc/rfc2251.txt
openldap/vendor/openldap-release/doc/rfc/rfc2252.txt
openldap/vendor/openldap-release/doc/rfc/rfc2253.txt
openldap/vendor/openldap-release/doc/rfc/rfc2254.txt
openldap/vendor/openldap-release/doc/rfc/rfc2255.txt
openldap/vendor/openldap-release/doc/rfc/rfc2256.txt
openldap/vendor/openldap-release/doc/rfc/rfc2293.txt
openldap/vendor/openldap-release/doc/rfc/rfc2294.txt
openldap/vendor/openldap-release/doc/rfc/rfc2307.txt
openldap/vendor/openldap-release/doc/rfc/rfc2377.txt
openldap/vendor/openldap-release/doc/rfc/rfc2587.txt
openldap/vendor/openldap-release/doc/rfc/rfc2589.txt
openldap/vendor/openldap-release/doc/rfc/rfc2649.txt
openldap/vendor/openldap-release/doc/rfc/rfc2696.txt
openldap/vendor/openldap-release/doc/rfc/rfc2713.txt
openldap/vendor/openldap-release/doc/rfc/rfc2714.txt
openldap/vendor/openldap-release/doc/rfc/rfc2798.txt
openldap/vendor/openldap-release/doc/rfc/rfc2829.txt
openldap/vendor/openldap-release/doc/rfc/rfc2830.txt
openldap/vendor/openldap-release/doc/rfc/rfc2849.txt
openldap/vendor/openldap-release/doc/rfc/rfc2891.txt
openldap/vendor/openldap-release/doc/rfc/rfc2926.txt
openldap/vendor/openldap-release/doc/rfc/rfc3045.txt
openldap/vendor/openldap-release/doc/rfc/rfc3062.txt
openldap/vendor/openldap-release/doc/rfc/rfc3088.txt
openldap/vendor/openldap-release/doc/rfc/rfc3112.txt
openldap/vendor/openldap-release/doc/rfc/rfc3296.txt
openldap/vendor/openldap-release/doc/rfc/rfc3377.txt
openldap/vendor/openldap-release/doc/rfc/rfc3383.txt
openldap/vendor/openldap-release/doc/rfc/rfc3663.txt
openldap/vendor/openldap-release/doc/rfc/rfc3671.txt
openldap/vendor/openldap-release/doc/rfc/rfc3672.txt
openldap/vendor/openldap-release/doc/rfc/rfc3673.txt
openldap/vendor/openldap-release/doc/rfc/rfc3674.txt
openldap/vendor/openldap-release/doc/rfc/rfc3687.txt
openldap/vendor/openldap-release/doc/rfc/rfc3698.txt
openldap/vendor/openldap-release/doc/rfc/rfc3703.txt
openldap/vendor/openldap-release/doc/rfc/rfc3712.txt
openldap/vendor/openldap-release/doc/rfc/rfc3727.txt
openldap/vendor/openldap-release/doc/rfc/rfc3771.txt
openldap/vendor/openldap-release/doc/rfc/rfc3829.txt
openldap/vendor/openldap-release/doc/rfc/rfc3866.txt
openldap/vendor/openldap-release/doc/rfc/rfc3876.txt
openldap/vendor/openldap-release/doc/rfc/rfc3909.txt
openldap/vendor/openldap-release/doc/rfc/rfc3928.txt
openldap/vendor/openldap-release/doc/rfc/rfc4013.txt
openldap/vendor/openldap-release/doc/rfc/rfc4370.txt
openldap/vendor/openldap-release/doc/rfc/rfc4373.txt
openldap/vendor/openldap-release/doc/rfc/rfc4403.txt
openldap/vendor/openldap-release/servers/slapd/schema/corba.schema
openldap/vendor/openldap-release/servers/slapd/schema/core.ldif
openldap/vendor/openldap-release/servers/slapd/schema/core.schema
openldap/vendor/openldap-release/servers/slapd/schema/cosine.schema
openldap/vendor/openldap-release/servers/slapd/schema/java.schema
openldap/vendor/openldap-release/servers/slapd/schema/ppolicy.schema
Modified:
openldap/vendor/openldap-release/CHANGES
openldap/vendor/openldap-release/build/openldap.m4
openldap/vendor/openldap-release/build/version.var
openldap/vendor/openldap-release/clients/tools/common.c
openldap/vendor/openldap-release/clients/tools/common.h
openldap/vendor/openldap-release/clients/tools/ldapcompare.c
openldap/vendor/openldap-release/clients/tools/ldapdelete.c
openldap/vendor/openldap-release/clients/tools/ldapmodify.c
openldap/vendor/openldap-release/clients/tools/ldapmodrdn.c
openldap/vendor/openldap-release/clients/tools/ldappasswd.c
openldap/vendor/openldap-release/clients/tools/ldapsearch.c
openldap/vendor/openldap-release/clients/tools/ldapwhoami.c
openldap/vendor/openldap-release/configure
openldap/vendor/openldap-release/configure.in
openldap/vendor/openldap-release/doc/guide/admin/guide.html
openldap/vendor/openldap-release/doc/man/man1/ldapsearch.1
openldap/vendor/openldap-release/doc/man/man5/slapd-bdb.5
openldap/vendor/openldap-release/doc/man/man5/slapd.conf.5
openldap/vendor/openldap-release/doc/man/man5/slapo-dynlist.5
openldap/vendor/openldap-release/doc/man/man5/slapo-ppolicy.5
openldap/vendor/openldap-release/doc/man/man8/slapadd.8
openldap/vendor/openldap-release/include/portable.hin
openldap/vendor/openldap-release/libraries/liblber/sockbuf.c
openldap/vendor/openldap-release/libraries/libldap/abandon.c
openldap/vendor/openldap-release/libraries/libldap/addentry.c
openldap/vendor/openldap-release/libraries/libldap/ldap-int.h
openldap/vendor/openldap-release/libraries/libldap/os-ip.c
openldap/vendor/openldap-release/libraries/libldap/os-local.c
openldap/vendor/openldap-release/libraries/libldap/request.c
openldap/vendor/openldap-release/libraries/libldap/search.c
openldap/vendor/openldap-release/libraries/libldap_r/thr_debug.c
openldap/vendor/openldap-release/libraries/liblutil/getpeereid.c
openldap/vendor/openldap-release/libraries/liblutil/passfile.c
openldap/vendor/openldap-release/libraries/liblutil/sockpair.c
openldap/vendor/openldap-release/servers/slapd/back-bdb/add.c
openldap/vendor/openldap-release/servers/slapd/back-bdb/back-bdb.h
openldap/vendor/openldap-release/servers/slapd/back-bdb/config.c
openldap/vendor/openldap-release/servers/slapd/back-bdb/filterindex.c
openldap/vendor/openldap-release/servers/slapd/back-bdb/index.c
openldap/vendor/openldap-release/servers/slapd/back-bdb/init.c
openldap/vendor/openldap-release/servers/slapd/back-bdb/modify.c
openldap/vendor/openldap-release/servers/slapd/back-bdb/search.c
openldap/vendor/openldap-release/servers/slapd/back-bdb/tools.c
openldap/vendor/openldap-release/servers/slapd/back-ldap/chain.c
openldap/vendor/openldap-release/servers/slapd/back-ldap/extended.c
openldap/vendor/openldap-release/servers/slapd/back-ldap/search.c
openldap/vendor/openldap-release/servers/slapd/back-ldbm/compare.c
openldap/vendor/openldap-release/servers/slapd/back-ldbm/ldbm.c
openldap/vendor/openldap-release/servers/slapd/back-meta/search.c
openldap/vendor/openldap-release/servers/slapd/back-perl/SampleLDAP.pm
openldap/vendor/openldap-release/servers/slapd/back-relay/config.c
openldap/vendor/openldap-release/servers/slapd/back-relay/op.c
openldap/vendor/openldap-release/servers/slapd/back-sql/entry-id.c
openldap/vendor/openldap-release/servers/slapd/backend.c
openldap/vendor/openldap-release/servers/slapd/backglue.c
openldap/vendor/openldap-release/servers/slapd/backover.c
openldap/vendor/openldap-release/servers/slapd/bconfig.c
openldap/vendor/openldap-release/servers/slapd/connection.c
openldap/vendor/openldap-release/servers/slapd/daemon.c
openldap/vendor/openldap-release/servers/slapd/dn.c
openldap/vendor/openldap-release/servers/slapd/entry.c
openldap/vendor/openldap-release/servers/slapd/init.c
openldap/vendor/openldap-release/servers/slapd/main.c
openldap/vendor/openldap-release/servers/slapd/overlays/Makefile.in
openldap/vendor/openldap-release/servers/slapd/overlays/dynlist.c
openldap/vendor/openldap-release/servers/slapd/overlays/pcache.c
openldap/vendor/openldap-release/servers/slapd/overlays/ppolicy.c
openldap/vendor/openldap-release/servers/slapd/overlays/rwm.c
openldap/vendor/openldap-release/servers/slapd/overlays/rwmmap.c
openldap/vendor/openldap-release/servers/slapd/overlays/syncprov.c
openldap/vendor/openldap-release/servers/slapd/overlays/translucent.c
openldap/vendor/openldap-release/servers/slapd/overlays/valsort.c
openldap/vendor/openldap-release/servers/slapd/proto-slap.h
openldap/vendor/openldap-release/servers/slapd/result.c
openldap/vendor/openldap-release/servers/slapd/sasl.c
openldap/vendor/openldap-release/servers/slapd/schema_init.c
openldap/vendor/openldap-release/servers/slapd/slap.h
openldap/vendor/openldap-release/servers/slapd/syncrepl.c
openldap/vendor/openldap-release/servers/slurpd/st.c
Log:
Load openldap-2.3.38 into openldap/vendor/openldap-release.
Modified: openldap/vendor/openldap-release/CHANGES
===================================================================
--- openldap/vendor/openldap-release/CHANGES 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/CHANGES 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,74 @@
OpenLDAP 2.3 Change Log
+OpenLDAP 2.3.38 Release (2007/08/20)
+ Fixed slapadd check for ';binary' when required (ITS#5071)
+ Fixed slapd select_backend/ManageDSAit (ITS#4986)
+ Fixed slapd integer/pointer types and overflow (ITS#5035)
+ Fixed slapd AVA_Sort on multivalued RDNs (ITS#5057)
+ Fixed slapd LDIF parsing error handling (ITS#5090)
+ Fixed slapd syncrepl searchbase scope (ITS#5073)
+ Fixed slapd-bdb missing index warning (ITS#5037)
+ Fixed slapd-bdb Quick index for ID 0 (ITS#5052)
+ Fixed slapd-bdb spurious empty DN warnings during add (ITS#5079)
+ Fixed slapd-hdb slapacl behavior (ITS#5087)
+ Fixed slapd-relay configuration (ITS#4322,ITS#4340)
+ Fixed slapd-sql structuralObjectClass issue (ITS#5088)
+ Fixed slapo-ppolicy double-free on shutdown (ITS#5094)
+ Fixed slapo-rwm/slapd-meta dup attrs after mapping (ITS#5091)
+ Fixed slapo-syncprov uninit'd vars (ITS#5048,#5049)
+ Fixed libldap ldap_add_result_entry (ITS#5056)
+ Added client tools support for ppolicy response (ITS#5061)
+ Removed lint
+ Build Environment
+ Fixed macro definition of open() in glibc 2.6 (ITS#5075)
+ Documentation
+ aspell --lang=en_US -c <manpage> (ITS#5076)
+ Debug messages cleaned up (ITS#5085)
+
+OpenLDAP 2.3.37 Release (2007/07/20)
+ Fixed slapd-glue/syncprov interaction (ITS#4623)
+ Fixed slapd-ldap search reference crash (ITS#5025)
+ Fixed slapd-ldbm crash on Compare op (ITS#5044)
+ Fixed slapo-rwm searchFilter double free (ITS#5043)
+ Clarified slapd-perl SampleLDAP.pm usage (ITS#4995)
+ Documentation
+ Fixed slapd.conf(5) for default loglevel (ITS#5027)
+
+OpenLDAP 2.3.36 Release (2007/06/17)
+ Fixed slapd error code on Windows (ITS#4945, #4606)
+ Fixed slapd mutex bug after failed startup (ITS#4957)
+ Fixed slapd sasl failed Bind bug (ITS#4954)
+ Fixed slapd sasl ssf logging (ITS#5001)
+ Fixed slapd tool op init (ITS#4911)
+ Fixed slapd-bdb no-op crasher (ITS#4925)
+ Fixed slapd-config olcLogLevel (ITS#4949)
+ Fixed slapd-config olcModuleLoad replace (ITS#4921,ITS#4923)
+ Fixed slapd-relay crash when no database can be selected (ITS#4958)
+ Fixed slapo-chain RFC3062 passwd exop handling (ITS#4964)
+ Fixed slapo-dynlist multiple group/url[/member] config (ITS#4989)
+ Fixed slapo-pcache handling of abandoned Operations (#5015)
+ Fixed slapo-pcache and -rwm interaction (ITS#4991)
+ Fixed slapo-ppolicy pwdReset/pwdMinAge (ITS#4970)
+ Fixed slapo-ppolicy control cleanup from ITS#4665
+ Fixed slapo-syncprov cookie parsing error (ITS#4977)
+ Fixed slapo-valsort crash on delete op (ITS#4966)
+ Fixed liblber compilation problem (ITS#5007)
+ Fixed libldap referral chasing loop (ITS#4955)
+ Fixed libldap response code handling on rebind (ITS#4924)
+ Fixed libldap SASL_MAX_BUFF_SIZE (ITS#4935)
+ Fixed libldap cldap assert (ITS#4992)
+ Fixed libldap_r thread debug issues (ITS#4972)
+ Fixed liblutil reading passwd from pipe (ITS#4875)
+ Fixed ldap client usage typo (ITS#4939)
+ Build Environment
+ Fixed --disable-overlays Makefile problem (ITS#4988)
+ Fixed HP-UX socklen_t problem (ITS#4629)
+ Documentation
+ Updated ldapsearch(1) with details on -C option (ITS#5009)
+ Updated slapadd(8) with details on -s option
+ Fixed slapd.conf(5) for correct loglevel packets (ITS#5011)
+ Fixed slapo-ppolicy(5) permanent pwdAccountLockedTime (ITS#4978)
+
OpenLDAP 2.3.35 Release (2007/04/09)
Fixed ldapmodify to use correct memory free functions (ITS#4901)
Fixed slapd acl set minor typo (ITS#4874)
@@ -178,7 +247,7 @@
Fixed slapo-syncprov need new CSN with delete syncID sets (ITS#4534)
Fixed slapo-syncprov startup when lastmod is off (ITS#4613)
Fixed slapo-accesslog cn=config purge bug (ITS#4595)
- Fixes slapo-auditlog DB initialization
+ Fixed slapo-auditlog DB initialization
Fixed slapo-ppolicy password hashing bug (ITS#4575)
Fixed slapo-ppolicy password modify pwdMustChange reset bug (ITS#4576)
Fixed slapo-ppolicy control can be critical (ITS#4596)
@@ -364,7 +433,7 @@
OpenLDAP 2.3.16 Release (2006/01/08)
Fixed slapd-bdb reindexing via cn=config not noticed issue (ITS#4260)
Fixed slapd-monitor connection search crash (ITS#4300)
- Flapd slapd cn=config bad ACL syntax modify crash (ITS#4306)
+ Fixed slapd cn=config bad ACL syntax modify crash (ITS#4306)
Fixed slapd ACL/suffix configuration issue (ITS#4307)
Fixed slapd-bdb/hdb cache issue (ITS#4308)
Fixed slapd-bdb/hdb/ldbm suffix add with default referral issue (ITS#4310)
Modified: openldap/vendor/openldap-release/build/openldap.m4
===================================================================
--- openldap/vendor/openldap-release/build/openldap.m4 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/build/openldap.m4 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
dnl OpenLDAP Autoconf Macros
-dnl $OpenLDAP: pkg/ldap/build/openldap.m4,v 1.140.2.12 2007/02/13 04:35:39 kurt Exp $
+dnl $OpenLDAP: pkg/ldap/build/openldap.m4,v 1.140.2.13 2007/08/06 12:32:51 ando Exp $
dnl This work is part of OpenLDAP Software <http://www.openldap.org/>.
dnl
dnl Copyright 1998-2007 The OpenLDAP Foundation.
@@ -627,9 +627,9 @@
}
#if (DB_VERSION_MAJOR > 3) || (DB_VERSION_MINOR >= 1)
- rc = env->open( env, NULL, flags, 0 );
+ rc = (env->open)( env, NULL, flags, 0 );
#else
- rc = env->open( env, NULL, NULL, flags, 0 );
+ rc = (env->open)( env, NULL, NULL, flags, 0 );
#endif
if ( rc == 0 ) {
Modified: openldap/vendor/openldap-release/build/version.var
===================================================================
--- openldap/vendor/openldap-release/build/version.var 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/build/version.var 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
#! /bin/sh
-# $OpenLDAP: pkg/ldap/build/version.var,v 1.7.2.85 2007/04/09 17:22:49 quanah Exp $
+# $OpenLDAP: pkg/ldap/build/version.var,v 1.7.2.94 2007/08/20 17:43:48 kurt Exp $
## This work is part of OpenLDAP Software <http://www.openldap.org/>.
##
## Copyright 1998-2007 The OpenLDAP Foundation.
@@ -15,9 +15,9 @@
ol_package=OpenLDAP
ol_major=2
ol_minor=3
-ol_patch=35
-ol_api_inc=20335
+ol_patch=38
+ol_api_inc=20338
ol_api_current=2
-ol_api_revision=23
+ol_api_revision=26
ol_api_age=2
-ol_release_date="2007/04/09"
+ol_release_date="2007/08/20"
Modified: openldap/vendor/openldap-release/clients/tools/common.c
===================================================================
--- openldap/vendor/openldap-release/clients/tools/common.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/clients/tools/common.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* common.c - common routines for the ldap client tools */
-/* $OpenLDAP: pkg/ldap/clients/tools/common.c,v 1.39.2.11 2007/04/01 22:44:09 quanah Exp $ */
+/* $OpenLDAP: pkg/ldap/clients/tools/common.c,v 1.39.2.13 2007/08/13 20:03:51 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -46,6 +46,8 @@
#include "ldap_defaults.h"
#include "ldap_pvt.h"
#include "lber_pvt.h"
+#include "lutil.h"
+#include "ldif.h"
#include "common.h"
@@ -87,6 +89,7 @@
int referrals = 0;
int protocol = -1;
int verbose = 0;
+int ldif = 0;
int version = 0;
#ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR
@@ -155,7 +158,7 @@
N_(" abandon, cancel (SIGINT sends abandon/cancel; not really controls)\n")
N_(" -f file read operations from `file'\n"),
N_(" -h host LDAP server\n"),
-N_(" -H URI LDAP Uniform Resource Indentifier(s)\n"),
+N_(" -H URI LDAP Uniform Resource Identifier(s)\n"),
N_(" -I use SASL Interactive mode\n"),
N_(" -k use Kerberos authentication\n"),
N_(" -K like -k, but do only step 1 of the Kerberos bind\n"),
@@ -1272,3 +1275,126 @@
return 0;
}
+#ifdef LDAP_CONTROL_PASSWORDPOLICYREQUEST
+static int
+print_ppolicy( LDAP *ld, LDAPControl *ctrl )
+{
+ int expire = 0, grace = 0, rc;
+ LDAPPasswordPolicyError pperr;
+
+ rc = ldap_parse_passwordpolicy_control( ld, ctrl,
+ &expire, &grace, &pperr );
+ if ( rc == LDAP_SUCCESS ) {
+ char buf[ BUFSIZ ], *ptr = buf;
+
+ if ( expire != -1 ) {
+ ptr += snprintf( ptr, sizeof( buf ) - ( ptr - buf ),
+ "expire=%d", expire );
+ }
+
+ if ( grace != -1 ) {
+ ptr += snprintf( ptr, sizeof( buf ) - ( ptr - buf ),
+ "%sgrace=%d", ptr == buf ? "" : " ", grace );
+ }
+
+ if ( pperr != PP_noError ) {
+ ptr += snprintf( ptr, sizeof( buf ) - ( ptr - buf ),
+ "%serror=%d (%s)", ptr == buf ? "" : " ",
+ pperr,
+ ldap_passwordpolicy_err2txt( pperr ) );
+ }
+
+ tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
+ "ppolicy", buf, ptr - buf );
+ }
+
+ return rc;
+}
+#endif
+
+void tool_print_ctrls(
+ LDAP *ld,
+ LDAPControl **ctrls )
+{
+ int i;
+ char *ptr;
+
+ for ( i = 0; ctrls[i] != NULL; i++ ) {
+ /* control: OID criticality base64value */
+ struct berval b64 = BER_BVNULL;
+ ber_len_t len;
+ char *str;
+ int j;
+
+ len = ldif ? 2 : 0;
+ len += strlen( ctrls[i]->ldctl_oid );
+
+ /* add enough for space after OID and the critical value itself */
+ len += ctrls[i]->ldctl_iscritical
+ ? sizeof("true") : sizeof("false");
+
+ /* convert to base64 */
+ if ( ctrls[i]->ldctl_value.bv_len ) {
+ b64.bv_len = LUTIL_BASE64_ENCODE_LEN(
+ ctrls[i]->ldctl_value.bv_len ) + 1;
+ b64.bv_val = ber_memalloc( b64.bv_len + 1 );
+
+ b64.bv_len = lutil_b64_ntop(
+ (unsigned char *) ctrls[i]->ldctl_value.bv_val,
+ ctrls[i]->ldctl_value.bv_len,
+ b64.bv_val, b64.bv_len );
+ }
+
+ if ( b64.bv_len ) {
+ len += 1 + b64.bv_len;
+ }
+
+ ptr = str = malloc( len + 1 );
+ if ( ldif ) {
+ ptr = lutil_strcopy( ptr, ": " );
+ }
+ ptr = lutil_strcopy( ptr, ctrls[i]->ldctl_oid );
+ ptr = lutil_strcopy( ptr, ctrls[i]->ldctl_iscritical
+ ? " true" : " false" );
+
+ if ( b64.bv_len ) {
+ ptr = lutil_strcopy( ptr, " " );
+ ptr = lutil_strcopy( ptr, b64.bv_val );
+ }
+
+ if ( ldif < 2 ) {
+ tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
+ "control", str, len );
+ }
+
+ free( str );
+ if ( b64.bv_len ) {
+ ber_memfree( b64.bv_val );
+ }
+
+ /* known controls */
+ if ( 0 ) {
+ /* dummy */ ;
+#ifdef LDAP_CONTROL_PASSWORDPOLICYREQUEST
+ } else if ( strcmp( LDAP_CONTROL_PASSWORDPOLICYRESPONSE, ctrls[i]->ldctl_oid ) == 0 ) {
+ (void)print_ppolicy( ld, ctrls[i] );
+#endif
+ }
+ }
+}
+
+int
+tool_write_ldif( int type, char *name, char *value, ber_len_t vallen )
+{
+ char *ldif;
+
+ if (( ldif = ldif_put( type, name, value, vallen )) == NULL ) {
+ return( -1 );
+ }
+
+ fputs( ldif, stdout );
+ ber_memfree( ldif );
+
+ return( 0 );
+}
+
Modified: openldap/vendor/openldap-release/clients/tools/common.h
===================================================================
--- openldap/vendor/openldap-release/clients/tools/common.h 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/clients/tools/common.h 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* common.h - common definitions for the ldap client tools */
-/* $OpenLDAP: pkg/ldap/clients/tools/common.h,v 1.11.2.7 2007/01/02 21:43:41 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/clients/tools/common.h,v 1.11.2.8 2007/08/13 20:03:51 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -61,6 +61,7 @@
extern int referrals;
extern int protocol;
extern int verbose;
+extern int ldif;
extern int version;
/* Defined in common.c, set in main() */
@@ -89,6 +90,8 @@
char *matched,
char *info,
char **refs ));
+void tool_print_ctrls LDAP_P(( LDAP *ld, LDAPControl **ctrls ));
+int tool_write_ldif LDAP_P(( int type, char *name, char *value, ber_len_t vallen ));
LDAP_END_DECL
Modified: openldap/vendor/openldap-release/clients/tools/ldapcompare.c
===================================================================
--- openldap/vendor/openldap-release/clients/tools/ldapcompare.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/clients/tools/ldapcompare.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* ldapcompare.c -- LDAP compare tool */
-/* $OpenLDAP: pkg/ldap/clients/tools/ldapcompare.c,v 1.34.2.5 2007/01/02 21:43:41 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/clients/tools/ldapcompare.c,v 1.34.2.6 2007/08/13 18:04:39 quanah Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -238,6 +238,7 @@
char *matcheddn;
char *text;
char **refs;
+ LDAPControl **ctrls = NULL;
if ( not ) {
return LDAP_SUCCESS;
@@ -270,7 +271,7 @@
}
}
- rc = ldap_parse_result( ld, res, &code, &matcheddn, &text, &refs, NULL, 1 );
+ rc = ldap_parse_result( ld, res, &code, &matcheddn, &text, &refs, &ctrls, 1 );
if( rc != LDAP_SUCCESS ) {
fprintf( stderr, "%s: ldap_parse_result: %s (%d)\n",
@@ -300,10 +301,6 @@
}
}
- ber_memfree( text );
- ber_memfree( matcheddn );
- ber_memvfree( (void **) refs );
-
/* if we were told to be quiet, use the return value. */
if ( !quiet ) {
if ( code == LDAP_COMPARE_TRUE ) {
@@ -315,6 +312,15 @@
}
}
+ if ( ctrls ) {
+ tool_print_ctrls( ld, ctrls );
+ ldap_controls_free( ctrls );
+ }
+
+ ber_memfree( text );
+ ber_memfree( matcheddn );
+ ber_memvfree( (void **) refs );
+
return( code );
}
Modified: openldap/vendor/openldap-release/clients/tools/ldapdelete.c
===================================================================
--- openldap/vendor/openldap-release/clients/tools/ldapdelete.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/clients/tools/ldapdelete.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* ldapdelete.c - simple program to delete an entry using LDAP */
-/* $OpenLDAP: pkg/ldap/clients/tools/ldapdelete.c,v 1.109.2.6 2007/01/02 21:43:41 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/clients/tools/ldapdelete.c,v 1.109.2.7 2007/08/13 18:04:39 quanah Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -211,6 +211,7 @@
int id;
int rc, code;
char *matcheddn = NULL, *text = NULL, **refs = NULL;
+ LDAPControl **ctrls = NULL;
LDAPMessage *res;
if ( verbose ) {
@@ -255,7 +256,7 @@
}
}
- rc = ldap_parse_result( ld, res, &code, &matcheddn, &text, &refs, NULL, 1 );
+ rc = ldap_parse_result( ld, res, &code, &matcheddn, &text, &refs, &ctrls, 1 );
if( rc != LDAP_SUCCESS ) {
fprintf( stderr, "%s: ldap_parse_result: %s (%d)\n",
@@ -287,6 +288,11 @@
}
}
+ if (ctrls) {
+ tool_print_ctrls( ld, ctrls );
+ ldap_controls_free( ctrls );
+ }
+
ber_memfree( text );
ber_memfree( matcheddn );
ber_memvfree( (void **) refs );
Modified: openldap/vendor/openldap-release/clients/tools/ldapmodify.c
===================================================================
--- openldap/vendor/openldap-release/clients/tools/ldapmodify.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/clients/tools/ldapmodify.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* ldapmodify.c - generic program to modify or add entries using LDAP */
-/* $OpenLDAP: pkg/ldap/clients/tools/ldapmodify.c,v 1.158.2.12 2007/04/01 22:44:23 quanah Exp $ */
+/* $OpenLDAP: pkg/ldap/clients/tools/ldapmodify.c,v 1.158.2.13 2007/08/13 20:03:51 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -1165,9 +1165,51 @@
}
if ( ldap_msgtype( res ) != LDAP_RES_INTERMEDIATE ) {
- rc = ldap_result2error( ld, res, 1 );
- if( rc != LDAP_SUCCESS ) ldap_perror( ld, opstr );
- return rc;
+ int code;
+ char *matcheddn = NULL, *text = NULL, **refs = NULL;
+ LDAPControl **ctrls = NULL;
+ rc = ldap_parse_result( ld, res, &code, &matcheddn, &text, &refs, &ctrls, 1 );
+
+ if ( rc != LDAP_SUCCESS ) {
+ fprintf( stderr, "%s: ldap_parse_result: %s (%d)\n",
+ prog, ldap_err2string( rc ), rc );
+ return rc;
+ }
+
+ if ( code != LDAP_SUCCESS ) {
+ tool_perror( prog, code, NULL, matcheddn, text, refs );
+ } else if ( verbose &&
+ ((matcheddn && *matcheddn) || (text && *text) || (refs && *refs) ))
+ {
+ printf( _("Delete Result: %s (%d)\n"),
+ ldap_err2string( code ), code );
+
+ if ( text && *text ) {
+ printf( _("Additional info: %s\n"), text );
+ }
+
+ if ( matcheddn && *matcheddn ) {
+ printf( _("Matched DN: %s\n"), matcheddn );
+ }
+
+ if ( refs ) {
+ int i;
+ for( i=0; refs[i]; i++ ) {
+ printf(_("Referral: %s\n"), refs[i] );
+ }
+ }
+ }
+
+ if (ctrls) {
+ tool_print_ctrls( ld, ctrls );
+ ldap_controls_free( ctrls );
+ }
+
+ ber_memfree( text );
+ ber_memfree( matcheddn );
+ ber_memvfree( (void **) refs );
+
+ return code;
}
#ifdef LDAP_GROUP_TRANSACTION
Modified: openldap/vendor/openldap-release/clients/tools/ldapmodrdn.c
===================================================================
--- openldap/vendor/openldap-release/clients/tools/ldapmodrdn.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/clients/tools/ldapmodrdn.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* ldapmodrdn.c - generic program to modify an entry's RDN using LDAP */
-/* $OpenLDAP: pkg/ldap/clients/tools/ldapmodrdn.c,v 1.106.2.6 2007/01/02 21:43:41 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/clients/tools/ldapmodrdn.c,v 1.106.2.7 2007/08/13 18:04:39 quanah Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -242,6 +242,7 @@
{
int rc, code, id;
char *matcheddn=NULL, *text=NULL, **refs=NULL;
+ LDAPControl **ctrls = NULL;
LDAPMessage *res;
if ( verbose ) {
@@ -285,7 +286,7 @@
}
}
- rc = ldap_parse_result( ld, res, &code, &matcheddn, &text, &refs, NULL, 1 );
+ rc = ldap_parse_result( ld, res, &code, &matcheddn, &text, &refs, &ctrls, 1 );
if( rc != LDAP_SUCCESS ) {
fprintf( stderr, "%s: ldap_parse_result: %s (%d)\n",
@@ -315,6 +316,11 @@
}
}
+ if (ctrls) {
+ tool_print_ctrls( ld, ctrls );
+ ldap_controls_free( ctrls );
+ }
+
ber_memfree( text );
ber_memfree( matcheddn );
ber_memvfree( (void **) refs );
Modified: openldap/vendor/openldap-release/clients/tools/ldappasswd.c
===================================================================
--- openldap/vendor/openldap-release/clients/tools/ldappasswd.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/clients/tools/ldappasswd.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* ldappasswd -- a tool for change LDAP passwords */
-/* $OpenLDAP: pkg/ldap/clients/tools/ldappasswd.c,v 1.127.2.6 2007/01/02 21:43:42 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/clients/tools/ldappasswd.c,v 1.127.2.7 2007/08/13 18:04:39 quanah Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -177,6 +177,7 @@
char *matcheddn = NULL, *text = NULL, **refs = NULL;
char *retoid = NULL;
struct berval *retdata = NULL;
+ LDAPControl **ctrls = NULL;
tool_init();
prog = lutil_progname( "ldappasswd", argc, argv );
@@ -310,6 +311,8 @@
goto done;
}
+ tool_server_controls( ld, NULL, 0);
+
rc = ldap_extended_operation( ld,
LDAP_EXOP_MODIFY_PASSWD, bv.bv_val ? &bv : NULL,
NULL, NULL, &id );
@@ -344,7 +347,7 @@
}
rc = ldap_parse_result( ld, res,
- &code, &matcheddn, &text, &refs, NULL, 0 );
+ &code, &matcheddn, &text, &refs, &ctrls, 0 );
if( rc != LDAP_SUCCESS ) {
ldap_perror( ld, "ldap_parse_result" );
rc = EXIT_FAILURE;
@@ -380,9 +383,17 @@
}
ber_free( ber, 1 );
+
+ } else if ( code == LDAP_SUCCESS && newpw.bv_val == NULL ) {
+ tool_perror( "ldap_parse_extended_result", LDAP_DECODING_ERROR,
+ " new password expected", NULL, NULL, NULL );
}
- if( verbose || code != LDAP_SUCCESS || matcheddn || text || refs ) {
+skip:
+ if( verbose || code != LDAP_SUCCESS ||
+ matcheddn || text || refs || ctrls )
+ {
+
printf( _("Result: %s (%d)\n"), ldap_err2string( code ), code );
if( text && *text ) {
@@ -399,6 +410,11 @@
printf(_("Referral: %s\n"), refs[i] );
}
}
+
+ if( ctrls ) {
+ tool_print_ctrls( ld, ctrls );
+ ldap_controls_free( ctrls );
+ }
}
ber_memfree( text );
Modified: openldap/vendor/openldap-release/clients/tools/ldapsearch.c
===================================================================
--- openldap/vendor/openldap-release/clients/tools/ldapsearch.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/clients/tools/ldapsearch.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* ldapsearch -- a tool for searching LDAP directories */
-/* $OpenLDAP: pkg/ldap/clients/tools/ldapsearch.c,v 1.207.2.11 2007/01/02 21:43:42 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/clients/tools/ldapsearch.c,v 1.207.2.12 2007/08/13 20:03:51 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -163,12 +163,6 @@
static void print_ctrls(
LDAPControl **ctrls );
-static int write_ldif LDAP_P((
- int type,
- char *name,
- char *value,
- ber_len_t vallen ));
-
static int dosearch LDAP_P((
LDAP *ld,
char *base,
@@ -186,7 +180,7 @@
static char *urlpre = NULL;
static char *base = NULL;
static char *sortattr = NULL;
-static int includeufn, vals2tmp = 0, ldif = 0;
+static int includeufn, vals2tmp = 0;
static int subentries = 0, valuesReturnFilter = 0;
static char *vrFilter = NULL;
@@ -1183,9 +1177,9 @@
if ( ldif < 2 ) {
ufn = ldap_dn2ufn( bv.bv_val );
- write_ldif( LDIF_PUT_COMMENT, NULL, ufn, ufn ? strlen( ufn ) : 0 );
+ tool_write_ldif( LDIF_PUT_COMMENT, NULL, ufn, ufn ? strlen( ufn ) : 0 );
}
- write_ldif( LDIF_PUT_VALUE, "dn", bv.bv_val, bv.bv_len );
+ tool_write_ldif( LDIF_PUT_VALUE, "dn", bv.bv_val, bv.bv_len );
rc = ldap_get_entry_controls( ld, entry, &ctrls );
if( rc != LDAP_SUCCESS ) {
@@ -1203,7 +1197,7 @@
if( ufn == NULL ) {
ufn = ldap_dn2ufn( bv.bv_val );
}
- write_ldif( LDIF_PUT_VALUE, "ufn", ufn, ufn ? strlen( ufn ) : 0 );
+ tool_write_ldif( LDIF_PUT_VALUE, "ufn", ufn, ufn ? strlen( ufn ) : 0 );
}
if( ufn != NULL ) ldap_memfree( ufn );
@@ -1217,7 +1211,7 @@
if (bv.bv_val == NULL) break;
if ( attrsonly ) {
- write_ldif( LDIF_PUT_NOVALUE, bv.bv_val, NULL, 0 );
+ tool_write_ldif( LDIF_PUT_NOVALUE, bv.bv_val, NULL, 0 );
} else if ( bvals ) {
for ( i = 0; bvals[i].bv_val != NULL; i++ ) {
@@ -1257,10 +1251,10 @@
&tmpfname[strlen(tmpdir) + sizeof(LDAP_DIRSEP) - 1] );
urlize( url );
- write_ldif( LDIF_PUT_URL, bv.bv_val, url, strlen( url ));
+ tool_write_ldif( LDIF_PUT_URL, bv.bv_val, url, strlen( url ));
} else {
- write_ldif( LDIF_PUT_VALUE, bv.bv_val,
+ tool_write_ldif( LDIF_PUT_VALUE, bv.bv_val,
bvals[ i ].bv_val, bvals[ i ].bv_len );
}
}
@@ -1295,7 +1289,7 @@
if( refs ) {
int i;
for( i=0; refs[i] != NULL; i++ ) {
- write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
+ tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
"ref", refs[i], strlen(refs[i]) );
}
ber_memvfree( (void **) refs );
@@ -1328,14 +1322,14 @@
}
if ( ldif < 2 ) {
- write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
+ tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
"extended", retoid, retoid ? strlen(retoid) : 0 );
}
ber_memfree( retoid );
if(retdata) {
if ( ldif < 2 ) {
- write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_BINARY,
+ tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_BINARY,
"data", retdata->bv_val, retdata->bv_len );
}
ber_bvfree( retdata );
@@ -1366,7 +1360,7 @@
}
if ( ldif < 2 ) {
- write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
+ tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
"partial", retoid, retoid ? strlen(retoid) : 0 );
}
@@ -1374,7 +1368,7 @@
if( retdata ) {
if ( ldif < 2 ) {
- write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_BINARY,
+ tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_BINARY,
"data", retdata->bv_val, retdata->bv_len );
}
@@ -1426,7 +1420,7 @@
if( matcheddn ) {
if( *matcheddn ) {
if( !ldif ) {
- write_ldif( LDIF_PUT_VALUE,
+ tool_write_ldif( LDIF_PUT_VALUE,
"matchedDN", matcheddn, strlen(matcheddn) );
} else {
fprintf( stderr, _("Matched DN: %s\n"), matcheddn );
@@ -1439,7 +1433,7 @@
if( text ) {
if( *text ) {
if( !ldif ) {
- write_ldif( LDIF_PUT_TEXT, "text",
+ tool_write_ldif( LDIF_PUT_TEXT, "text",
text, strlen(text) );
} else {
fprintf( stderr, _("Additional information: %s\n"), text );
@@ -1453,7 +1447,7 @@
int i;
for( i=0; refs[i] != NULL; i++ ) {
if( !ldif ) {
- write_ldif( LDIF_PUT_VALUE, "ref", refs[i], strlen(refs[i]) );
+ tool_write_ldif( LDIF_PUT_VALUE, "ref", refs[i], strlen(refs[i]) );
} else {
fprintf( stderr, _("Referral: %s\n"), refs[i] );
}
@@ -1521,7 +1515,7 @@
}
if ( ldif < 2 ) {
- write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
+ tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
"control", str, len );
}
@@ -1530,22 +1524,6 @@
}
}
-static int
-write_ldif( int type, char *name, char *value, ber_len_t vallen )
-{
- char *ldif;
-
- if (( ldif = ldif_put( type, name, value, vallen )) == NULL ) {
- return( -1 );
- }
-
- fputs( ldif, stdout );
- ber_memfree( ldif );
-
- return( 0 );
-}
-
-
#ifdef LDAP_CONTROL_PAGEDRESULTS
static int
parse_page_control(
Modified: openldap/vendor/openldap-release/clients/tools/ldapwhoami.c
===================================================================
--- openldap/vendor/openldap-release/clients/tools/ldapwhoami.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/clients/tools/ldapwhoami.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* ldapwhoami.c -- a tool for asking the directory "Who Am I?" */
-/* $OpenLDAP: pkg/ldap/clients/tools/ldapwhoami.c,v 1.33.2.5 2007/01/02 21:43:42 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/clients/tools/ldapwhoami.c,v 1.33.2.6 2007/08/13 18:04:39 quanah Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -118,6 +118,7 @@
struct berval *retdata = NULL;
int id, code=0;
LDAPMessage *res;
+ LDAPControl **ctrls = NULL;
tool_init();
prog = lutil_progname( "ldapwhoami", argc, argv );
@@ -161,7 +162,7 @@
rc = ldap_whoami( ld, NULL, NULL, &id );
if( rc != LDAP_SUCCESS ) {
- ldap_perror( ld, "ldap_extended_operation" );
+ ldap_perror( ld, "ldap_whoami" );
rc = EXIT_FAILURE;
goto skip;
}
@@ -188,7 +189,7 @@
}
rc = ldap_parse_result( ld, res,
- &code, &matcheddn, &text, &refs, NULL, 0 );
+ &code, &matcheddn, &text, &refs, &ctrls, 0 );
if( rc != LDAP_SUCCESS ) {
ldap_perror( ld, "ldap_parse_result" );
@@ -212,7 +213,10 @@
}
}
- if( verbose || ( code != LDAP_SUCCESS ) || matcheddn || text || refs ) {
+skip:
+ if ( verbose || ( code != LDAP_SUCCESS ) ||
+ matcheddn || text || refs || ctrls )
+ {
printf( _("Result: %s (%d)\n"), ldap_err2string( code ), code );
if( text && *text ) {
@@ -229,6 +233,11 @@
printf(_("Referral: %s\n"), refs[i] );
}
}
+
+ if (ctrls) {
+ tool_print_ctrls( ld, ctrls );
+ ldap_controls_free( ctrls );
+ }
}
ber_memfree( text );
@@ -237,7 +246,6 @@
ber_memfree( retoid );
ber_bvfree( retdata );
-skip:
/* disconnect from server */
tool_unbind( ld );
tool_destroy();
Modified: openldap/vendor/openldap-release/configure
===================================================================
--- openldap/vendor/openldap-release/configure 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/configure 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
#! /bin/sh
-# From configure.in OpenLDAP: pkg/ldap/configure.in,v 1.560.2.32 2007/01/02 21:43:40 kurt Exp .
+# From configure.in OpenLDAP: pkg/ldap/configure.in,v 1.560.2.33 2007/06/10 18:39:53 hallvard Exp .
# Guess values for system-dependent variables and create Makefiles.
# Generated by GNU Autoconf 2.59.
#
@@ -35722,9 +35722,9 @@
}
#if (DB_VERSION_MAJOR > 3) || (DB_VERSION_MINOR >= 1)
- rc = env->open( env, NULL, flags, 0 );
+ rc = (env->open)( env, NULL, flags, 0 );
#else
- rc = env->open( env, NULL, NULL, flags, 0 );
+ rc = (env->open)( env, NULL, NULL, flags, 0 );
#endif
if ( rc == 0 ) {
@@ -39558,6 +39558,7 @@
fi
+
echo "$as_me:$LINENO: checking for socklen_t" >&5
echo $ECHO_N "checking for socklen_t... $ECHO_C" >&6
if test "${ac_cv_type_socklen_t+set}" = set; then
@@ -39574,7 +39575,6 @@
#include <sys/socket.h>
#endif
-
int
main ()
{
@@ -39619,14 +39619,86 @@
fi
echo "$as_me:$LINENO: result: $ac_cv_type_socklen_t" >&5
echo "${ECHO_T}$ac_cv_type_socklen_t" >&6
-if test $ac_cv_type_socklen_t = yes; then
- :
+
+
+echo "$as_me:$LINENO: checking the type of arg 3 to accept()" >&5
+echo $ECHO_N "checking the type of arg 3 to accept()... $ECHO_C" >&6
+if test "${ol_cv_type_ber_socklen_t+set}" = set; then
+ echo $ECHO_N "(cached) $ECHO_C" >&6
else
+ set socklen_t int unsigned "unsigned long" long size_t
+ test "$ac_cv_type_socklen_t" = yes || shift
+ ol_cv_type_ber_socklen_t=$1 guessing="guessing "
+ for lentype in "$@" ; do for addrtype in "struct sockaddr" void ; do
+ cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h. */
+$ac_includes_default
+#ifdef HAVE_SYS_SOCKET_H
+#include <sys/socket.h>
+#endif
+extern int accept(int s, $addrtype *ap, $lentype *lp);
+
+int
+main ()
+{
+
+accept(0, (struct sockaddr *) 0, ($lentype *) 0);
+
+ ;
+ return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+ (eval $ac_compile) 2>conftest.er1
+ ac_status=$?
+ grep -v '^ *+' conftest.er1 >conftest.err
+ rm -f conftest.er1
+ cat conftest.err >&5
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); } &&
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
+ { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+ (eval $ac_try) 2>&5
+ ac_status=$?
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); }; } &&
+ { ac_try='test -s conftest.$ac_objext'
+ { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+ (eval $ac_try) 2>&5
+ ac_status=$?
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); }; }; then
+ ol_cv_type_ber_socklen_t=$lentype guessing= ; break 2
+else
+ echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+ done ; done
+fi
+
+echo "$as_me:$LINENO: result: $guessing$ol_cv_type_ber_socklen_t *" >&5
+echo "${ECHO_T}$guessing$ol_cv_type_ber_socklen_t *" >&6
+
cat >>confdefs.h <<_ACEOF
-#define socklen_t int
+#define ber_socklen_t $ol_cv_type_ber_socklen_t
_ACEOF
+
+if test "$ac_cv_type_socklen_t" != yes; then
+
+cat >>confdefs.h <<_ACEOF
+#define socklen_t $ol_cv_type_ber_socklen_t
+_ACEOF
+
fi
Modified: openldap/vendor/openldap-release/configure.in
===================================================================
--- openldap/vendor/openldap-release/configure.in 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/configure.in 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,4 +1,4 @@
-dnl $OpenLDAP: pkg/ldap/configure.in,v 1.560.2.32 2007/01/02 21:43:40 kurt Exp $
+dnl $OpenLDAP: pkg/ldap/configure.in,v 1.560.2.33 2007/06/10 18:39:53 hallvard Exp $
dnl This work is part of OpenLDAP Software <http://www.openldap.org/>.
dnl
dnl Copyright 1998-2007 The OpenLDAP Foundation.
@@ -25,7 +25,7 @@
dnl Configure.in for OpenLDAP
AC_COPYRIGHT([[Copyright 1998-2007 The OpenLDAP Foundation. All rights reserved.
Restrictions apply, see COPYRIGHT and LICENSE files.]])
-AC_REVISION([$OpenLDAP: pkg/ldap/configure.in,v 1.560.2.32 2007/01/02 21:43:40 kurt Exp $])
+AC_REVISION([$OpenLDAP: pkg/ldap/configure.in,v 1.560.2.33 2007/06/10 18:39:53 hallvard Exp $])
AC_INIT([OpenLDAP],,[http://www.openldap.org/its/])
m4_define([AC_PACKAGE_BUGREPORT],[<http://www.openldap.org/its/>])
AC_CONFIG_SRCDIR(build/version.sh)dnl
@@ -2378,15 +2378,44 @@
AC_CHECK_TYPES([long long])
AC_CHECK_TYPES([ptrdiff_t])
-AC_CHECK_TYPE([socklen_t],,
- [AC_DEFINE_UNQUOTED([socklen_t], [int],
- [Define to `int' if <sys/socket.h> does not define.])],
- [$ac_includes_default
+
+AC_CHECK_TYPE([socklen_t],,, [$ac_includes_default
#ifdef HAVE_SYS_SOCKET_H
#include <sys/socket.h>
+#endif])
+
+dnl socklen_t-like type in accept(), default socklen_t or int:
+dnl - The OS might define socklen_t without using it. POSIX moved from
+dnl int to size_t to socklen_t, hoping to stay at a 32-bit type, and
+dnl HP-UX now has selectors for what to use.
+dnl - On Solaris 2.8 the prototype has void *len, but the default is OK.
+AC_MSG_CHECKING([the type of arg 3 to accept()])
+AC_CACHE_VAL(ol_cv_type_ber_socklen_t, [
+ set socklen_t int unsigned "unsigned long" long size_t
+ test "$ac_cv_type_socklen_t" = yes || shift
+ ol_cv_type_ber_socklen_t=$1 guessing="guessing "
+ for lentype in "$@" ; do for addrtype in "struct sockaddr" void ; do
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([$ac_includes_default
+#ifdef HAVE_SYS_SOCKET_H
+#include <sys/socket.h>
#endif
- ])
+extern int accept(int s, $addrtype *ap, $lentype *lp);
+], [
+accept(0, (struct sockaddr *) 0, ($lentype *) 0);
+])], [ol_cv_type_ber_socklen_t=$lentype guessing= ; break 2])
+ done ; done])
+AC_MSG_RESULT([$guessing$ol_cv_type_ber_socklen_t *])
+AC_DEFINE_UNQUOTED(ber_socklen_t, $ol_cv_type_ber_socklen_t,
+ [Define to the type of arg 3 for `accept'.])
+dnl Modules should use ber_socklen_t, not socklen_t. Define socklen_t
+dnl for the time being anyway, for backwards compatibility.
+if test "$ac_cv_type_socklen_t" != yes; then
+ AC_DEFINE_UNQUOTED([socklen_t], [$ol_cv_type_ber_socklen_t],
+ [Define like ber_socklen_t if <sys/socket.h> does not define.])
+fi
+
+
AC_TYPE_SIGNAL
AC_CHECK_TYPE([sig_atomic_t],,
Added: openldap/vendor/openldap-release/doc/drafts/README
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/README (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/README 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,18 @@
+Internet-Drafts (I-Ds) are working documents of the Internet
+Engineering Task Force (IETF), its areas, its working groups, and
+individual contributors.
+
+I-Ds are only 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 I-Ds as reference material or to cite them
+other than as "work in progress."
+
+The OpenLDAP Project maintains copies of I-D for which we find
+interesting. Existance here does not necessarily imply any support
+nor any plans to support for the I-D. The I-Ds found in this
+directory may be stale, expired, or otherwise out of date.
+
+Please go to <http://www.ietf.org/> for latest revisions (and
+status).
+
+$OpenLDAP: pkg/ldap/doc/drafts/README,v 1.8 2003/12/07 06:54:38 kurt Exp $
Added: openldap/vendor/openldap-release/doc/drafts/draft-behera-ldap-password-policy-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-behera-ldap-password-policy-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-behera-ldap-password-policy-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,2298 @@
+
+
+
+
+Network Working Group J. Sermersheim
+Internet-Draft Novell, Inc
+Expires: January 18, 2006 L. Poitou
+ Sun Microsystems
+ July 17, 2005
+
+
+ Password Policy for LDAP Directories
+ draft-behera-ldap-password-policy-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 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/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on January 18, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ Password policy as described in this document is a set of rules that
+ controls how passwords are used and administered in Lightweight
+ Directory Access Protocol (LDAP) based directories. In order to
+ improve the security of LDAP directories and make it difficult for
+ password cracking programs to break into directories, it is desirable
+ to enforce a set of rules on password usage. These rules are made to
+ ensure that users change their passwords periodically, passwords meet
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 1]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ construction requirements, the re-use of old password is restricted,
+ and users are locked out after a certain number of failed attempts.
+
+Discussion Forum
+
+ Technical discussion of this document will take place on the IETF
+ LDAP Extensions mailing list <ldapext at ietf.org>. Please send
+ editorial comments directly to the authors.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 2]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+Table of Contents
+
+ 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Application of password policy . . . . . . . . . . . . . . . . 6
+ 4. Articles of password policy . . . . . . . . . . . . . . . . . 7
+ 4.1 Password Usage Policy . . . . . . . . . . . . . . . . . . . . 7
+ 4.2 Password Modification Policy . . . . . . . . . . . . . . . . . 7
+ 4.3 Restriction of the Password Policy . . . . . . . . . . . . . . 10
+ 5. Schema used for Password Policy . . . . . . . . . . . . . . . 11
+ 5.1 The pwdPolicy Object Class . . . . . . . . . . . . . . . . . . 11
+ 5.2 Attribute Types used in the pwdPolicy ObjectClass . . . . . . 11
+ 5.3 Attribute Types for Password Policy State Information . . . . 16
+ 6. Controls used for Password Policy . . . . . . . . . . . . . . 21
+ 6.1 Request Control . . . . . . . . . . . . . . . . . . . . . . . 21
+ 6.2 Response Control . . . . . . . . . . . . . . . . . . . . . . . 21
+ 7. Policy Decision Points . . . . . . . . . . . . . . . . . . . . 23
+ 7.1 Locked Account Check . . . . . . . . . . . . . . . . . . . . . 23
+ 7.2 Password Must be Changed Now Check . . . . . . . . . . . . . . 23
+ 7.3 Password Expiration Check . . . . . . . . . . . . . . . . . . 23
+ 7.4 Remaining Grace AuthN Check . . . . . . . . . . . . . . . . . 23
+ 7.5 Time Before Expiration Check . . . . . . . . . . . . . . . . . 24
+ 7.6 Intruder Detection Check . . . . . . . . . . . . . . . . . . . 24
+ 7.7 Password Too Young Check . . . . . . . . . . . . . . . . . . . 24
+ 8. Server Policy Enforcement Points . . . . . . . . . . . . . . . 25
+ 8.1 Password-based Authentication . . . . . . . . . . . . . . . . 25
+ 8.2 Password Update Operations . . . . . . . . . . . . . . . . . . 27
+ 8.3 Other Operations . . . . . . . . . . . . . . . . . . . . . . . 30
+ 9. Client Policy Enforcement Points . . . . . . . . . . . . . . . 31
+ 9.1 Bind Operation . . . . . . . . . . . . . . . . . . . . . . . . 31
+ 9.2 Modify Operations . . . . . . . . . . . . . . . . . . . . . . 32
+ 9.3 Add Operation . . . . . . . . . . . . . . . . . . . . . . . . 33
+ 9.4 Compare Operation . . . . . . . . . . . . . . . . . . . . . . 33
+ 9.5 Other Operations . . . . . . . . . . . . . . . . . . . . . . . 34
+ 10. Administration of the Password Policy . . . . . . . . . . . . 35
+ 11. Password Policy and Replication . . . . . . . . . . . . . . . 36
+ 12. Security Considerations . . . . . . . . . . . . . . . . . . . 37
+ 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
+ 14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 39
+ 15. Normative References . . . . . . . . . . . . . . . . . . . . . 39
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 40
+ Intellectual Property and Copyright Statements . . . . . . . . 41
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 3]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+1. Overview
+
+ LDAP-based directory services are currently accepted by many
+ organizations as the access protocol for directories. The ability to
+ ensure the secure read and update access to directory information
+ throughout the network is essential to the successful deployment.
+ Most LDAP implementations support many authentication schemes - the
+ most basic and widely used is the simple authentication i.e., user DN
+ and password. In this case, many LDAP servers have implemented some
+ kind of policy related to the password used to authenticate. Among
+ other things, this policy includes:
+
+ o Whether and when passwords expire.
+
+ o Whether failed bind attempts cause the account to be locked.
+
+ o If and how users are able to change their passwords.
+
+ In order to achieve greater security protection and ensure
+ interoperability in a heterogeneous environment, LDAP needs to
+ standardize on a common password policy model. This is critical to
+ the successful deployment of LDAP directories.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 4]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+2. Conventions
+
+ Imperative keywords defined in [RFC2119] are used in this document,
+ and carry the meanings described there.
+
+ All Basic Encoding Rules (BER) [X690] encodings follow the
+ conventions found in Section 5.1 of [RFC2251].
+
+ The term "password administrator" refers to a user that has
+ sufficient access control privileges to modify users' passwords. The
+ term "password policy administrator" refers to a user that has
+ sufficient access control privileges to modify the pwdPolicy object
+ defined in this document. The access control that is used to
+ determine whether an identity is a password administrator or password
+ policy administrator is beyond the scope of this document, but
+ typically implies that the password administrator has 'write'
+ privileges to the password attribute.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 5]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+3. Application of password policy
+
+ The password policy defined in this document can be applied to any
+ attribute holding a user's password used for an authenticated LDAP
+ bind operation. In this document, the term "user" represents any
+ LDAP client application that has an identity in the directory.
+
+ This policy is typically applied to the userPassword attribute in the
+ case of the LDAP simple authentication method [RFC2251] or the case
+ of password based SASL [RFC2222] authentication such as CRAM-MD5
+ [RFC2195] and DIGEST-MD5 [RFC2831].
+
+ The policy described in this document assumes that the password
+ attribute holds a single value. No considerations are made for
+ directories or systems that allow a user to maintain multi-valued
+ password attributes.
+
+ Server implementations MAY institute internal policy whereby certain
+ identities (such as directory administrators) are not forced to
+ comply with any of password policy. In this case, the password for a
+ directory administrator never expires; the account is never locked,
+ etc.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 6]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+4. Articles of password policy
+
+ The following sections explain in general terms each aspect of the
+ password policy defined in this document as well as the need for
+ each. These policies are subdivided into the general groups of
+ password usage and password modification. Implementation details are
+ presented in Section 8 and Section 9.
+
+4.1 Password Usage Policy
+
+ This section describes policy enforced when a password is used to
+ authenticate. The general focus of this policy is to minimize the
+ threat of intruders once a password is in use.
+
+4.1.1 Password Guessing Limit
+
+ In order to prevent intruders from guessing a user's password, a
+ mechanism exists to track the number of consecutive failed
+ authentication attempts, and take action when a limit is reached.
+ This policy consists of five parts:
+
+ o A configurable limit on failed authentication attempts.
+
+ o A counter to track the number of failed authentication attempts.
+
+ o A timeframe in which the limit of consecutive failed
+ authentication attempts must happen before action is taken.
+
+ o The action to be taken when the limit is reached. The action will
+ either be nothing, or the account will be locked.
+
+ o An amount of time the account is locked (if it is to be locked).
+ This can be indefinite.
+
+
+4.2 Password Modification Policy
+
+ This section describes policy enforced while users are modifying
+ passwords. The general focus of this policy is to ensure that when
+ users add or change their passwords, the security and effectiveness
+ of their passwords is maximized. In this document, the term "modify
+ password operation" refers to any operation that is used to add or
+ modify a password attribute. Often this is done by updating the
+ password attribute during an add or modify operation, but MAY be done
+ by other means such as an extended operation.
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 7]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+4.2.1 Password Expiration, Expiration Warning, and Grace
+ Authentications
+
+ One of the key properties of a password is the fact that it is not
+ well known. If a password is frequently changed, the chances of that
+ user's account being broken into are minimized.
+
+ Password policy administrators may deploy a password policy that
+ causes passwords to expire after a given amount of time - thus
+ forcing users to change their passwords periodically.
+
+ As a side effect, there needs to be a way in which users are made
+ aware of this need to change their password before actually being
+ locked out of their accounts. One or both of the following methods
+ handle this:
+
+ o A warning may be returned to the user sometime before his password
+ is due to expire. If the user fails to heed this warning before
+ the expiration time, his account will be locked.
+
+ o The user may bind to the directory a preset number of times after
+ her password has expired. If she fails to change her password
+ during one of her 'grace' authentications, her account will be
+ locked.
+
+
+4.2.2 Password History
+
+ When the Password Expiration policy is used, an additional mechanism
+ may be employed to prevent users from simply re-using a previous
+ password (as this would effectively circumvent the expiration
+ policy).
+
+ In order to do this; a history of used passwords is kept. The
+ password policy administrator sets the number of passwords to be
+ stored at any given time. Passwords are stored in this history
+ whenever the password is changed. Users aren't allowed to specify
+ any passwords that are in the history list while changing passwords.
+
+4.2.3 Password Minimum Age
+
+ Users may circumvent the Password History mechanism by quickly
+ performing a series of password changes. If they change their
+ password enough times, their 'favorite' password will be pushed out
+ of the history list.
+
+ This process may be made less attractive to users by employing a
+ minimum age for passwords. If users are forced to wait 24 hours
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 8]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ between password changes, they may be less likely to cycle through a
+ history of 10 passwords.
+
+4.2.4 Password Quality and Minimum length
+
+ In order to prevent users from creating or updating passwords that
+ are easy to guess, a password quality policy may be employed. This
+ policy consists of two general mechanisms - ensuring that passwords
+ conform to a defined quality criterion and ensuring that they are of
+ a minimum length.
+
+ Forcing a password to comply with the quality policy may imply a
+ variety of things including:
+
+ o Disallowing trivial or well-known words make up the password.
+
+ o Forcing a certain number of digits be used.
+
+ o Disallowing anagrams of the user's name.
+
+ The implementation of this policy meets with the following problems:
+
+ o If the password to be added or updated is encrypted by the client
+ before being sent, the server has no way of enforcing this policy.
+ Therefore, the onus of enforcing this policy falls upon client
+ implementations.
+
+ o There are no specific definitions of what 'quality checking'
+ means. This can lead to unexpected behavior in a heterogeneous
+ environment.
+
+
+4.2.5 User Defined Passwords
+
+ In some cases, it is desirable to disallow users from adding and
+ updating their own passwords. This policy makes this functionality
+ possible.
+
+4.2.6 Password Change after Reset
+
+ This policy forces the user to update her password after it has been
+ set for the first time, or has been reset by a password
+ administrator.
+
+ This is needed in scenarios where a password administrator has set or
+ reset the password to a well-known value.
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 9]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+4.2.7 Safe Modification
+
+ As directories become more commonly used, it will not be unusual for
+ clients to connect to a directory and leave the connection open for
+ an extended period. This opens up the possibility for an intruder to
+ make modifications to a user's password while that user's computer is
+ connected but unattended.
+
+ This policy forces the user to prove his identity by specifying the
+ old password during a password modify operation.
+
+ {TODO: This allows a dictionary attack unless we specify that this is
+ also subject to intruder detection. One solution is to require users
+ to authN prior to changing password. Another solution is to perform
+ intruder detection checks when the password for a non-authenticated
+ identity is being updated}
+
+4.3 Restriction of the Password Policy
+
+ The password policy defined in this document can apply to any
+ attribute containing a password. Password policy state information
+ is held in the user's entry, and applies to a password attribute, not
+ a particular password attribute value. Thus the server SHOULD
+ enforce that the password attribute subject to password policy,
+ contains one and only one password value.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 10]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+5. Schema used for Password Policy
+
+ The schema elements defined here fall into two general categories. A
+ password policy object class is defined which contains a set of
+ administrative password policy attributes, and a set of operational
+ attributes are defined that hold general password policy state
+ information for each user.
+
+5.1 The pwdPolicy Object Class
+
+ This object class contains the attributes defining a password policy
+ in effect for a set of users. Section 10 describes the
+ administration of this object, and the relationship between it and
+ particular objects.
+
+ ( 1.3.6.1.4.1.42.2.27.8.2.1
+ NAME 'pwdPolicy'
+ SUP top
+ AUXILIARY
+ MUST ( pwdAttribute )
+ MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $
+ pwdMinLength $ pwdExpireWarning $ pwdGraceAuthNLimit $ pwdLockout
+ $ pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $
+ pwdMustChange $ pwdAllowUserChange $ pwdSafeModify ) )
+
+
+5.2 Attribute Types used in the pwdPolicy ObjectClass
+
+ Following are the attribute types used by the pwdPolicy object class.
+
+5.2.1 pwdAttribute
+
+ This holds the name of the attribute to which the password policy is
+ applied. For example, the password policy may be applied to the
+ userPassword attribute.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.1
+ NAME 'pwdAttribute'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+
+5.2.2 pwdMinAge
+
+ This attribute holds the number of seconds that must elapse between
+ modifications to the password. If this attribute is not present, 0
+ seconds is assumed.
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 11]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.2
+ NAME 'pwdMinAge'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+
+5.2.3 pwdMaxAge
+
+ This attribute holds the number of seconds after which a modified
+ password will expire.
+
+ If this attribute is not present, or if the value is 0 the password
+ does not expire. If not 0, the value must be greater than or equal
+ to the value of the pwdMinAge.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.3
+ NAME 'pwdMaxAge'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+
+5.2.4 pwdInHistory
+
+ This attribute specifies the maximum number of used passwords stored
+ in the pwdHistory attribute.
+
+ If this attribute is not present, or if the value is 0, used
+ passwords are not stored in the pwdHistory attribute and thus may be
+ reused.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.4
+ NAME 'pwdInHistory'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+
+5.2.5 pwdCheckQuality
+
+ {TODO: Consider changing the syntax to OID. Each OID will list a
+ quality rule (like min len, # of special characters, etc). These
+ rules can be specified outside this document.}
+
+ {TODO: Note that even though this is meant to be a check that happens
+ during password modification, it may also be allowed to happen during
+ authN. This is useful for situations where the password is encrypted
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 12]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ when modified, but decrypted when used to authN.}
+
+ This attribute indicates how the password quality will be verified
+ while being modified or added. If this attribute is not present, or
+ if the value is '0', quality checking will not be enforced. A value
+ of '1' indicates that the server will check the quality, and if the
+ server is unable to check it (due to a hashed password or other
+ reasons) it will be accepted. A value of '2' indicates that the
+ server will check the quality, and if the server is unable to verify
+ it, it will return an error refusing the password.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.5
+ NAME 'pwdCheckQuality'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+
+5.2.6 pwdMinLength
+
+ When quality checking is enabled, this attribute holds the minimum
+ number of characters that must be used in a password. If this
+ attribute is not present, no minimum password length will be
+ enforced. If the server is unable to check the length (due to a
+ hashed password or otherwise), the server will, depending on the
+ value of the pwdCheckQuality attribute, either accept the password
+ without checking it ('0' or '1') or refuse it ('2').
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.6
+ NAME 'pwdMinLength'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+
+5.2.7 pwdExpireWarning
+
+ This attribute specifies the maximum number of seconds before a
+ password is due to expire that expiration warning messages will be
+ returned to an authenticating user.
+
+ If this attribute is not present, or if the value is 0 no warnings
+ will be returned. If not 0, the value must be smaller than the value
+ of the pwdMaxAge attribute.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.7
+ NAME 'pwdExpireWarning'
+ EQUALITY integerMatch
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 13]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+
+5.2.8 pwdGraceAuthNLimit
+
+ This attribute specifies the number of times an expired password can
+ be used to authenticate. If this attribute is not present or if the
+ value is 0, authentication will fail.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.8
+ NAME 'pwdGraceAuthNLimit'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+
+5.2.9 pwdLockout
+
+ This attribute indicates, when its value is "TRUE", that the password
+ may not be used to authenticate after a specified number of
+ consecutive failed bind attempts. The maximum number of consecutive
+ failed bind attempts is specified in pwdMaxFailure.
+
+ If this attribute is not present, or if the value is "FALSE", the
+ password may be used to authenticate when the number of failed bind
+ attempts has been reached.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.9
+ NAME 'pwdLockout'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+
+5.2.10 pwdLockoutDuration
+
+ This attribute holds the number of seconds that the password cannot
+ be used to authenticate due to too many failed bind attempts. If
+ this attribute is not present, or if the value is 0 the password
+ cannot be used to authenticate until reset by a password
+ administrator.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.10
+ NAME 'pwdLockoutDuration'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 14]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+5.2.11 pwdMaxFailure
+
+ This attribute specifies the number of consecutive failed bind
+ attempts after which the password may not be used to authenticate.
+ If this attribute is not present, or if the value is 0, this policy
+ is not checked, and the value of pwdLockout will be ignored.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.11
+ NAME 'pwdMaxFailure'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+
+5.2.12 pwdFailureCountInterval
+
+ This attribute holds the number of seconds after which the password
+ failures are purged from the failure counter, even though no
+ successful authentication occurred.
+
+ If this attribute is not present, or if its value is 0, the failure
+ counter is only reset by a successful authentication.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.12
+ NAME 'pwdFailureCountInterval'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+
+5.2.13 pwdMustChange
+
+ This attribute specifies with a value of "TRUE" that users must
+ change their passwords when they first bind to the directory after a
+ password is set or reset by a password administrator. If this
+ attribute is not present, or if the value is "FALSE", users are not
+ required to change their password upon binding after the password
+ administrator sets or resets the password. This attribute is not set
+ due to any actions specified by this document, it is typically set by
+ a password administrator after resetting a user's password.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.13
+ NAME 'pwdMustChange'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 15]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+5.2.14 pwdAllowUserChange
+
+ This attribute indicates whether users can change their own
+ passwords, although the change operation is still subject to access
+ control. If this attribute is not present, a value of "TRUE" is
+ assumed. This attribute is intended to be used in the absense of an
+ access control mechanism.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.14
+ NAME 'pwdAllowUserChange'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+
+5.2.15 pwdSafeModify
+
+ This attribute specifies whether or not the existing password must be
+ sent along with the new password when being changed. If this
+ attribute is not present, a "FALSE" value is assumed.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.15
+ NAME 'pwdSafeModify'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+
+5.3 Attribute Types for Password Policy State Information
+
+ Password policy state information must be maintained for each user.
+ The information is located in each user entry as a set of operational
+ attributes. These operational attributes are: pwdChangedTime,
+ pwdAccountLockedTime, pwdFailureTime, pwdHistory, pwdGraceUseTime,
+ pwdReset, pwdPolicySubEntry.
+
+5.3.1 Password Policy State Attribute Option
+
+ Since the password policy could apply to several attributes used to
+ store passwords, each of the above operational attributes must have
+ an option to specify which pwdAttribute it applies to. The password
+ policy option is defined as the following:
+
+ pwd-<passwordAttribute>
+
+ where passwordAttribute a string following the OID syntax
+ (1.3.6.1.4.1.1466.115.121.1.38). The attribute type descriptor
+ (short name) MUST be used.
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 16]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ For example, if the pwdPolicy object has for pwdAttribute
+ "userPassword" then the pwdChangedTime operational attribute, in a
+ user entry, will be:
+
+ pwdChangedTime;pwd-userPassword: 20000103121520Z
+
+ This attribute option follows sub-typing semantics. If a client
+ requests a password policy state attribute to be returned in a search
+ operation, and does not specify an option, all subtypes of that
+ policy state attribute are returned.
+
+5.3.2 pwdChangedTime
+
+ This attribute specifies the last time the entry's password was
+ changed. This is used by the password expiration policy. If this
+ attribute does not exist, the password will never expire.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.16
+ NAME 'pwdChangedTime'
+ DESC 'The time the password was last changed'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+
+5.3.3 pwdAccountLockedTime
+
+ This attribute holds the time that the user's account was locked. A
+ locked account means that the password may no longer be used to
+ authenticate. A 000001010000Z value means that the account has been
+ locked permanently, and that only a password administrator can unlock
+ the account.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.17
+ NAME 'pwdAccountLockedTime'
+ DESC 'The time an user account was locked'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 17]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+5.3.4 pwdFailureTime
+
+ This attribute holds the timestamps of the consecutive authentication
+ failures.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.19
+ NAME 'pwdFailureTime'
+ DESC 'The timestamps of the last consecutive authentication
+ failures'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+
+5.3.5 pwdHistory
+
+ This attribute holds a history of previously used passwords. Values
+ of this attribute are transmitted in string format as given by the
+ following ABNF:
+
+ pwdHistory = time "#" syntaxOID "#" length "#" data
+
+ time = <generalizedTimeString as specified in 6.14
+ of [RFC2252]>
+
+ syntaxOID = numericoid ; the string representation of the
+ ; dotted-decimal OID that defines the
+ ; syntax used to store the password.
+ ; numericoid is described in 4.1
+ ; of [RFC2252].
+
+ length = numericstring ; the number of octets in data.
+ ; numericstring is described in 4.1
+ ; of [RFC2252].
+
+ data = <octets representing the password in the format
+ specified by syntaxOID>.
+
+ This format allows the server to store, and transmit a history of
+ passwords that have been used. In order for equality matching to
+ function properly, the time field needs to adhere to a consistent
+ format. For this purpose, the time field MUST be in GMT format.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.20
+ NAME 'pwdHistory'
+ DESC 'The history of user s passwords'
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 18]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ EQUALITY octetStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+
+5.3.6 pwdGraceUseTime
+
+ This attribute holds the timestamps of grace authentications after a
+ password has expired.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.21
+ NAME 'pwdGraceUseTime'
+ DESC 'The timestamps of the grace authentication after the
+ password has expired'
+ EQUALITY generalizedTimeMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+
+5.3.7 pwdReset
+
+ This attribute holds a flag to indicate (when TRUE) that the password
+ has been updated by the password administrator and must be changed by
+ the user.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.22
+ NAME 'pwdReset'
+ DESC 'The indication that the password has been reset'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE
+ USAGE directoryOperation )
+
+
+5.3.8 pwdPolicySubentry
+
+ This attribute points to the pwdPolicy subentry in effect for this
+ object.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.23
+ NAME 'pwdPolicySubentry'
+ DESC 'The pwdPolicy subentry in effect for this object'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 19]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ USAGE directoryOperation )
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 20]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+6. Controls used for Password Policy
+
+ This section details the controls used while enforcing password
+ policy. A request control is defined that is sent by a client with a
+ request operation in order to elicit a response control. The
+ response control contains various warnings and errors associated with
+ password policy.
+
+ {TODO: add a note about advertisement and discovery}
+
+6.1 Request Control
+
+ This control MAY be sent with any LDAP request message in order to
+ convey to the server that this client is aware of, and can process
+ the response control described in this document. When a server
+ receives this control, it will return the response control when
+ appropriate and with the proper data.
+
+ The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality may
+ be TRUE or FALSE. There is no controlValue.
+
+6.2 Response Control
+
+ If the client has sent a passwordPolicyRequest control, the server
+ (when solicited by the inclusion of the request control) sends this
+ control with the following operation responses: bindResponse,
+ modifyResponse, addResponse, compareResponse and possibly
+ extendedResponse, to inform of various conditions, and MAY be sent
+ with other operations (in the case of the changeAfterReset error).
+ The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the controlValue is
+ the BER encoding of the following type:
+
+ PasswordPolicyResponseValue ::= SEQUENCE {
+ warning [0] CHOICE {
+ timeBeforeExpiration [0] INTEGER (0 .. maxInt),
+ graceAuthNsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL,
+ error [1] ENUMERATED {
+ passwordExpired (0),
+ accountLocked (1),
+ changeAfterReset (2),
+ passwordModNotAllowed (3),
+ mustSupplyOldPassword (4),
+ insufficientPasswordQuality (5),
+ passwordTooShort (6),
+ passwordTooYoung (7),
+ passwordInHistory (8) } OPTIONAL }
+
+ The timeBeforeExpiration warning specifies the number of seconds
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 21]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ before a password will expire. The graceAuthNsRemaining warning
+ specifies the remaining number of times a user will be allowed to
+ authenticate with an expired password. The passwordExpired error
+ signifies that the password has expired and must be reset. The
+ changeAfterReset error signifies that the password must be changed
+ before the user will be allowed to perform any operation other than
+ bind and modify. The passwordModNotAllowed error is set when a user
+ is restricted from changing her password. The
+ insufficientPasswordQuality error is set when a password doesn't pass
+ quality checking. The passwordTooYoung error is set if the age of
+ the password to be modified is not yet old enough.
+
+ Typically, only either a warning or an error will be encoded though
+ there may be exceptions. For example, if the user is required to
+ change a password after the password administrator set it, and the
+ password will expire in a short amount of time, the control may
+ include the timeBeforeExpiration warning and the changeAfterReset
+ error.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 22]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+7. Policy Decision Points
+
+ Following are a number of procedures used to make policy decisions.
+ These procedures are typically performed by the server while
+ processing an operation.
+
+ The following sections contain detailed instructions that refer to
+ attributes of the pwdPolicy object class. When doing so, the
+ attribute of the pwdPolicy object that governs the entry being
+ discussed is implied.
+
+7.1 Locked Account Check
+
+ A status of true is returned to indicate that the account is locked
+ if any of these conditions are met:
+
+ o The value of the pwdAccountLockedTime attribute is 000001010000Z.
+
+ o The current time is less than the value of the
+ pwdAccountLockedTime attribute added to the value of the
+ pwdLockoutDuration.
+
+ Otherwise a status of false is returned.
+
+7.2 Password Must be Changed Now Check
+
+ A status of true is returned to indicate that the account is locked
+ if all of these conditions are met:
+
+ The pwdMustChange attribute is set to TRUE.
+
+ The pwdReset attribute is set to TRUE.
+
+ Otherwise a status of false is returned.
+
+7.3 Password Expiration Check
+
+ A status of true is returned indicating that the password has expired
+ if the current time minus the value of pwdChangedTime is greater than
+ the value of the pwdMaxAge.
+
+ Otherwise, a status of false is returned.
+
+7.4 Remaining Grace AuthN Check
+
+ If the pwdGraceUseTime attribute is present, the number of values in
+ that attribute subtracted from the value of pwdGraceAuthNLimit is
+ returned. Otherwise zero is returned. A positive result specifies
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 23]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ the number of remaining grace authentications.
+
+7.5 Time Before Expiration Check
+
+ If the pwdExpireWarning attribute is not present a zero status is
+ returned. Otherwise the following steps are followed:
+
+ Subtract the time stored in pwdChangedTime from the current time to
+ arrive at the password's age. If the password's age is greater than
+ than the value of the pwdMaxAge attribute, a zero status is returned.
+ Subtract the value of the pwdExpireWarning attribute from the value
+ of the pwdMaxAge attribute to arrive at the warning age. If the
+ password's age is equal to or greater than the warning age, the value
+ of pwdMaxAge minus the password's age is returned.
+
+7.6 Intruder Detection Check
+
+ A status of true indicating that an intruder has been detected is
+ returned if the following conditions are met:
+
+ The pwdLockout attribute is TRUE.
+
+ The number of values in the pwdFailureTime attribute that are
+ younger than pwdFailureCountInterval is greater or equal to the
+ pwdMaxFailure attribute.
+
+ Otherwise a status of false is returned.
+
+ While performing this check, values of pwdFailureTime that are old by
+ more than pwdFailureCountInterval are purged and not counted.
+
+7.7 Password Too Young Check
+
+ A status of true indicating that not enough time has passed since the
+ password was last updated is returned if:
+
+ The value of pwdMinAge is non-zero and pwdChangedTime is present.
+
+ The value of pwdMinAge is greater than the current time minus the
+ value of pwdChangedTime.
+
+ Otherwise a false status is returned.
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 24]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+8. Server Policy Enforcement Points
+
+ The server SHOULD enforce that the password attribute subject to a
+ password policy as defined in this document, contains one and only
+ one password value.
+
+ The scenarios in the following operations assume that the client has
+ attached a passwordPolicyRequest control to the request message of
+ the operation. In the event that the passwordPolicyRequest control
+ was not sent, no passwordPolicyResponse control is returned. All
+ other instructions remain the same.
+
+ For successfuly completed operations, unless otherwise stated, no
+ passwordPolicyResponse control is returned.
+
+8.1 Password-based Authentication
+
+ This section contains the policy enforcement rules and policy data
+ updates used while validating a password. Operations that validate
+ passwords include, but are not limited to, the Bind operation where
+ the simple choice specifies a password, and the compare operation
+ where the attribute being compared holds a password. Note that while
+ the compare operation does not authenticate a user to the LDAP
+ server, it may be used by an external application for purposes of
+ authentication.
+
+8.1.1 Fail if the account is locked
+
+ If the account is locked as specified in Section 7.1, the server
+ fails the operation with an appropriate resultCode (i.e.
+ invalidCredentials (49) in the case of a bind operation, compareFalse
+ (5) in the case of a compare operation, etc.). The server MAY set
+ the error: accountLocked (1) in the passwordPolicyResponse in the
+ controls field of the message.
+
+8.1.2 Validated Password Procedures
+
+ If the validation operation indicates that the password validated,
+ these procedures are followed in order:
+
+8.1.2.1 Policy state updates
+
+ Delete the pwdFailureTime and pwdAccountLockedTime attributes.
+
+8.1.2.2 Password must be changed now
+
+ If the decision in Section 7.2 returns true, the server sends to the
+ client a response with an appropriate successful resultCode (i.e.
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 25]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ success (0), compareTrue (6), etc.), and includes the
+ passwordPolicyResponse in the controls field of the bindResponse
+ message with the warning: changeAfterReset specified.
+
+ For bind, the server MUST then disallow all operations issued by this
+ user except modify password, bind, unbind, abandon and StartTLS
+ extended operation.
+
+8.1.2.3 Expired password
+
+ If the password has expired as per Section 7.3, the server either
+ returns a success or failure based on the state of grace
+ authentications.
+
+8.1.2.3.1 Remaining Grace Authentications
+
+ If there are remaining grace authentications as per Section 7.4, the
+ server adds a new value with the current time in pwdGraceUseTime.
+ Then it sends to the client a response with an appropriate successful
+ resultCode (i.e. success (0), compareTrue (6), etc.), and includes
+ the passwordPolicyResponse in the controls field of the response
+ message with the warning: graceAuthNsRemaining choice set to the
+ number of grace authentications left.
+
+ Implementor's note: The system time of the host machine may be more
+ granular than is needed to ensure unique values of this attribute.
+ It is recommended that a mechanism is used to ensure unique
+ generalized time values. The fractional seconds field may be used
+ for this purpose.
+
+8.1.2.3.2 No Remaining Grace Authentications
+
+ If there are no remaining grace authentications, the server fails the
+ operation with an appropriate resultCode (invalidCredentials (49),
+ compareFalse (5), etc.), and includes the passwordPolicyResponse in
+ the controls field of the bindResponse message with the error:
+ passwordExpired (0) set.
+
+8.1.2.4 Expiration Warning
+
+ If the result of Section 7.5 is a positive number, the server sends
+ to the client a response with an appropriate successful resultCode
+ (i.e. success (0), compareTrue (6), etc.), and includes the
+ passwordPolicyResponse in the controls field of the bindResponse
+ message with the warning: timeBeforeExiration set to the value as
+ described above. Otherwise, the server sends a successful response,
+ and omits the passwordPolicyResponse.
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 26]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+8.1.2.5 AuthN Failed Procedures
+
+ If the authentication process indicates that the password failed
+ validation due to invalid credentials, these procedures are followed:
+
+8.1.2.5.1 Policy state update
+
+ Add the current time as a value of the pwdFailureTime attribute.
+
+ Implementor's note: The system time of the host machine may be more
+ granular than is needed to ensure unique values of this attribute.
+ It is recommended that a mechanism is used to ensure unique
+ generalized time values. The fractional seconds field may be used
+ for this purpose.
+
+8.1.2.5.2 Lock on intruder detection
+
+ If the check in Section 7.6 returns a true state, the server locks
+ the account by setting the value of the pwdAccountLockedTime
+ attribute to the current time. After locking the account, the server
+ fails the operation with an appropriate resultCode
+ (invalidCredentials (49), compareFalse (5), etc.), and includes the
+ passwordPolicyResponse in the controls field of the message with the
+ error: accountLocked (1).
+
+8.2 Password Update Operations
+
+ Because the password is stored in an attribute, various operations
+ (like add and modify) may be used to create or update a password.
+ But some alternate mechanisms have been defined or may be defined,
+ such as the LDAP Password Modify Extended Operation [RFC3062].
+
+ While processing a password update, the server performs the following
+ steps:
+
+8.2.1 Safe Modification
+
+ If pwdSafeModify is set to TRUE and if there is an existing password
+ value, the server ensures that the password update operation includes
+ the user's existing password.
+
+ When the LDAP modify operation is used to modify a password, this is
+ done by specifying both a delete action and an add or replace action,
+ where the delete action specifies the existing password, and the add
+ or replace action specifies the new password. Other password update
+ operations SHOULD employ a similar mechanism. Otherwise this policy
+ will fail.
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 27]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ If the existing password is not specified, the server does not
+ process the operation and sends the appropriate response message to
+ the client with the resultCode: insufficientAccessRights (50), and
+ includes the passwordPolicyResponse in the controls field of the
+ response message with the error: mustSupplyOldPassword (4).
+
+8.2.2 Change After Reset
+
+ If the decision in Section 7.2 returns true, the server ensures that
+ the password update operation contains no modifications other than
+ the modification of the password attribute. If other modifications
+ exist, the server sends a response message to the client with the
+ resultCode: insufficientAccessRights (50), and includes the
+ passwordPolicyResponse in the controls field of the response message
+ with the error: changeAfterReset (2).
+
+8.2.3 Rights Check
+
+ Check to see whether the bound identity has sufficient rights to
+ update the password. If the bound identity is a user changing its
+ own password, this MAY be done by checking the pwdAllowUserChange
+ attribute or using an access control mechanism. The determination of
+ this is implementation specific. If the user is not allowed to
+ update her password, the server sends a response message to the
+ client with the resultCode: insufficientAccessRights (50), and
+ includes the passwordPolicyResponse in the controls field of the
+ response message with the error: passwordModNotAllowed (3).
+
+8.2.4 Too Early to Update
+
+ If the check in Section 7.7 results in a true status The server sends
+ a response message to the client with the resultCode:
+ constraintViolation (19), and includes the passwordPolicyResponse in
+ the controls field of the response message with the error:
+ passwordTooYoung (7).
+
+8.2.5 Password Quality
+
+ Check the value of the pwdCheckQuality attribute. If the value is
+ non-zero, the server:
+
+ o Ensure that the password meets the quality criteria enforced by
+ the server. This enforcement is implementation specific.
+ If the server is unable to check the quality (due to a hashed
+ password or otherwise), the value of pwdCheckQuality is evaluated.
+ If the value is 1, operation continues. If the value is 2, the
+ server sends a response message to the client with the resultCode:
+ constraintViolation (19), and includes the passwordPolicyResponse
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 28]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ in the controls field of the response message with the error:
+ insufficientPasswordQuality (5).
+ If the server is able to check the password quality, and the check
+ fails, the server sends a response message to the client with the
+ resultCode: constraintViolation (19), and includes the
+ passwordPolicyResponse in the controls field of the response
+ message with the error: insufficientPasswordQuality (5).
+
+ o checks the value of the pwdMinLength attribute. If the value is
+ non-zero, it ensures that the new password is of at least the
+ minimum length.
+ If the server is unable to check the length (due to a hashed
+ password or otherwise), the value of pwdCheckQuality is evaluated.
+ If the value is 1, operation continues. If the value is 2, the
+ server sends a response message to the client with the resultCode:
+ constraintViolation (19), and includes the passwordPolicyResponse
+ in the controls field of the response message with the error:
+ passwordTooShort (6).
+ If the server is able to check the password length, and the check
+ fails, the server sends a response message to the client with the
+ resultCode: constraintViolation (19), and includes the
+ passwordPolicyResponse in the controls field of the response
+ message with the error: passwordTooShort (6).
+
+
+8.2.6 Invalid Reuse
+
+ If pwdInHistory is present and its value is non-zero, the server
+ checks whether this password exists in the entry's pwdHistory
+ attribute or in the current password attribute. If the password does
+ exist in the pwdHistory attribute or in the current password
+ attribute, the server sends a response message to the client with the
+ resultCode: constraintViolation (19), and includes the
+ passwordPolicyResponse in the controls field of the response message
+ with the error: passwordInHistory (8).
+
+8.2.7 Policy State Updates
+
+ If the steps have completed without causing an error condition, the
+ server performs the following steps in order to update the necessary
+ password policy state attributes:
+
+ If the value of either pwdMaxAge or pwdMinAge is non-zero, the server
+ updates the pwdChangedTime attribute on the entry to the current
+ time.
+
+ If the value of pwdInHistory is non-zero, the server adds the
+ previous password (if one existed) to the pwdHistory attribute. If
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 29]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ the number of attributes held in the pwdHistory attribute exceeds the
+ value of pwdInHistory, the server removes the oldest excess
+ passwords.
+
+ If the value the pwdMustChange is TRUE and the modification is
+ performed by a password administrator, then the pwdReset attribute is
+ set to TRUE. Otherwise, the pwdReset is removed from the user's
+ entry if it exists.
+
+ The pwdFailureTime and pwdGraceUseTime attributes is removed from the
+ user's entry if they exist.
+
+8.3 Other Operations
+
+ For operations other than bind, password update, unbind, abandon or
+ StartTLS, if the decision in Section 7.2 returns true, the server
+ sends a response message to the client with the resultCode:
+ insufficientAccessRights (50), and includes the
+ passwordPolicyResponse in the controls field of the response message
+ with the error: changeAfterReset (2).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 30]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+9. Client Policy Enforcement Points
+
+ These sections illustrate possible scenarios for each LDAP operation
+ and define the types of responses that identify those scenarios.
+
+ The scenarios in the following operations assume that the client
+ attached a passwordPolicyRequest control to the request message of
+ the operation, and thus may receive a passwordPolicyResponse control
+ in the response message. In the event that the passwordPolicyRequest
+ control was not sent, no passwordPolicyResponse control is returned.
+ All other instructions remain the same.
+
+9.1 Bind Operation
+
+ For every bind response received, the client checks the resultCode of
+ the bindResponse and checks for a passwordPolicyResponse control to
+ determine if any of the following conditions are true and MAY prompt
+ the user accordingly.
+
+ o bindResponse.resultCode = insufficientAccessRights (50),
+ passwordPolicyResponse.error = accountLocked (1): The password
+ failure limit has been reached and the account is locked. The
+ user needs to retry later or contact the password administrator to
+ reset the password.
+
+ o bindResponse.resultCode = success (0),
+ passwordPolicyResponse.error = changeAfterReset (2): The user is
+ binding for the first time after the password administrator set
+ the password. In this scenario, the client SHOULD prompt the user
+ to change his password immediately.
+
+ o bindResponse.resultCode = success (0),
+ passwordPolicyResponse.warning = graceAuthNsRemaining: The
+ password has expired but there are remaining grace
+ authentications. The user needs to change it.
+
+ o bindResponse.resultCode = invalidCredentials (49),
+ passwordPolicyResponse.error = passwordExpired (0): The password
+ has expired and there are no more grace authentications. The user
+ contacts the password administrator in order to have its password
+ reset.
+
+ o bindResponse.resultCode = success (0),
+ passwordPolicyResponse.warning = timeBeforeExpiration: The user's
+ password will expire in n number of seconds.
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 31]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+9.2 Modify Operations
+
+9.2.1 Modify Request
+
+ If the application or client encrypts the password prior to sending
+ it in a password modification operation (whether done through
+ modifyRequest or another password modification mechanism), it SHOULD
+ check the values of the pwdMinLength, and pwdCheckQuality attributes
+ and SHOULD enforce these policies.
+
+9.2.2 Modify Response
+
+ If the modifyRequest operation was used to change the password, or if
+ another mechanism is used --such as an extendedRequest-- the
+ modifyResponse or other appropriate response MAY contain information
+ pertinent to password policy. The client checks the resultCode of
+ the response and checks for a passwordPolicyResponse control to
+ determine if any of the following conditions are true and optionally
+ notify the user of the condition.
+
+ o <pwdModResponse>.resultCode = insufficientAccessRights (50),
+ passwordPolicyResponse.error = mustSupplyOldPassword (4): The user
+ attempted to change her password without specifying the old
+ password but the password policy requires this.
+
+ o <pwdModResponse>.resultCode = insufficientAccessRights (50),
+ passwordPolicyResponse.error = changeAfterReset (2): The user must
+ change her password before submitting any other LDAP requests.
+
+ o <pwdModResponse>.resultCode = insufficientAccessRights (50),
+ passwordPolicyResponse.error = passwordModNotAllowed (3): The user
+ doesn't have sufficient rights to change his password.
+
+ o <pwdModResponse>.resultCode = constraintViolation (19),
+ passwordPolicyResponse.error = passwordTooYoung (7): It is too
+ soon after the last password modification to change the password.
+
+ o <pwdModResponse>.resultCode = constraintViolation (19),
+ passwordPolicyResponse.error = insufficientPasswordQuality (5):
+ The password failed quality checking.
+
+ o <pwdModResponse>.resultCode = constraintViolation (19),
+ passwordPolicyResponse.error = passwordTooShort (6): The length of
+ the password is too short.
+
+ o <pwdModResponse>.resultCode = constraintViolation (19),
+ passwordPolicyResponse.error = passwordInHistory (8): The password
+ has already been used; the user must choose a different one.
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 32]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+9.3 Add Operation
+
+ If a password is specified in an addRequest, the client checks the
+ resultCode of the addResponse and checks for a passwordPolicyResponse
+ control to determine if any of the following conditions are true and
+ may prompt the user accordingly.
+
+ o addResponse.resultCode = insufficientAccessRights (50),
+ passwordPolicyResponse.error = passwordModNotAllowed (3): The user
+ doesn't have sufficient rights to add this password.
+
+ o addResponse.resultCode = constraintViolation (19),
+ passwordPolicyResponse.error = insufficientPasswordQuality (5):
+ The password failed quality checking.
+
+ o addResponse.resultCode = constraintViolation (19),
+ passwordPolicyResponse.error = passwordTooShort (6): The length of
+ the password is too short.
+
+
+9.4 Compare Operation
+
+ When a compare operation is used to compare a password, the client
+ checks the resultCode of the compareResponse and checks for a
+ passwordPolicyResponse to determine if any of the following
+ conditions are true and MAY prompt the user accordingly. These
+ conditions assume that the result of the comparison was true.
+
+ o compareResponse.resultCode = compareFalse (5),
+ passwordPolicyResponse.error = accountLocked (1): The password
+ failure limit has been reached and the account is locked. The
+ user needs to retry later or contact the password administrator to
+ reset the password.
+
+ o compareResponse.resultCode = compareTrue (6),
+ passwordPolicyResponse.warning = graceAuthNsRemaining: The
+ password has expired but there are remaining grace
+ authentications. The user needs to change it.
+
+ o compareResponse.resultCode = compareFalse (5),
+ passwordPolicyResponse.error = passwordExpired (0): The password
+ has expired and there are no more grace authentications. The user
+ must contact the password administrator to reset the password.
+
+ o compareResponse.resultCode = compareTrue (6),
+ passwordPolicyResponse.warning = timeBeforeExpiration: The user's
+ password will expire in n number of seconds.
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 33]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+9.5 Other Operations
+
+ For operations other than bind, unbind, abandon or StartTLS, the
+ client checks the following result code and control to determine if
+ the user needs to change the password immediately.
+
+ o <Response>.resultCode = insufficientAccessRights (50),
+ passwordPolicyResponse.error = : changeAfterReset (2)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 34]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+10. Administration of the Password Policy
+
+ {TODO: Need to define an administrativeRole (need OID). Need to
+ describe whether pwdPolicy admin areas can overlap}
+
+ A password policy is defined for a particular subtree of the DIT by
+ adding to an LDAP subentry whose immediate superior is the root of
+ the subtree, the pwdPolicy auxiliary object class. The scope of the
+ password policy is defined by the SubtreeSpecification attribute of
+ the LDAP subentry as specified in [RFC3672].
+
+ It is possible to define password policies for different password
+ attributes within the same pwdPolicy entry, by specifying multiple
+ values of the pwdAttribute. But password policies could also be in
+ separate sub entries as long as they are contained under the same
+ LDAP subentry.
+
+ Modifying the password policy MUST NOT result in any change in users'
+ entries to which the policy applies.
+
+ It SHOULD be possible to overwrite the password policy for one user
+ by defining a new policy in a subentry of the user entry.
+
+ Each object that is controlled by password policy advertises the
+ subentry that is being used to control its policy in its
+ pwdPolicySubentry attribute. Clients wishing to examine or manage
+ password policy for an object may interrogate the pwdPolicySubentry
+ for that object in order to arrive at the proper pwdPolicy subentry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 35]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+11. Password Policy and Replication
+
+ {TODO: This section needs to be changed to highlight the pitfals of
+ replication, sugest some implementation choices to overcome those
+ pitfals, but remove prescriptive language relating to the update of
+ state information}
+
+ The pwdPolicy object defines the password policy for a portion of the
+ DIT and MUST be replicated on all the replicas of this subtree, as
+ any subentry would be, in order to have a consistent policy among all
+ replicated servers.
+
+ The elements of the password policy that are related to the users are
+ stored in the entry themselves as operational attributes. As these
+ attributes are subject to modifications even on a read-only replica,
+ replicating them must be carefully considered.
+
+ The pwdChangedTime attribute MUST be replicated on all replicas, to
+ allow expiration of the password.
+
+ The pwdReset attribute MUST be replicated on all replicas, to deny
+ access to operations other than bind and modify password.
+
+ The pwdHistory attribute MUST be replicated to writable replicas. It
+ doesn't have to be replicated to a read-only replica, since the
+ password will never be directly modified on this server.
+
+ The pwdAccountLockedTime, pwdFailureTime and pwdGraceUseTime
+ attributes MUST be replicated to writable replicas, making the
+ password policy global for all servers. When the user entry is
+ replicated to a read-only replica, these attributes SHOULD NOT be
+ replicated. This means that the number of failures, of grace
+ authentications and the locking will take place on each replicated
+ server. For example, the effective number of failed attempts on a
+ user password will be N x M (where N is the number of servers and M
+ the value of pwdMaxFailure attribute). Replicating these attributes
+ to a read-only replica MAY reduce the number of tries globally but
+ MAY also introduce some inconstancies in the way the password policy
+ is applied.
+
+ Servers participating in a loosely consistent multi-master
+ replication agreement SHOULD employ a mechanism which ensures
+ uniqueness of values when populating the attributes pwdFailureTime
+ and pwdGraceUseTime. The method of achieving this is a local matter
+ and may consist of using a single authoritative source for the
+ generation of unique time values, or may consist of the use of the
+ fractional seconds part to hold a replica identifier.
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 36]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+12. Security Considerations
+
+ This document defines a set of rules to implement in an LDAP server,
+ in order to mitigate some of the security risks associated with the
+ use of passwords and to make it difficult for password cracking
+ programs to break into directories.
+
+ Authentication with a password MUST follow the recommendations made
+ in [RFC2829].
+
+ Modifications of passwords SHOULD only occur when the connection is
+ protected with confidentiality and secure authentication.
+
+ Access controls SHOULD be used to restrict access to the password
+ policy attributes. The attributes defined to maintain the password
+ policy state information SHOULD only be modifiable by the password
+ administrator or higher authority. The pwdHistory attribute MUST be
+ subject to the same level of access control as the attrbute holding
+ the password.
+
+ As it is possible to define a password policy for one specific user
+ by adding a subentry immediately under the user's entry, Access
+ Controls SHOULD be used to restrict the use of the pwdPolicy object
+ class or the LDAP subentry object class.
+
+ When the intruder detection password policy is enforced, the LDAP
+ directory is subject to a denial of service attack. A malicious user
+ could deliberately lock out one specific user's account (or all of
+ them) by sending bind requests with wrong passwords. There is no way
+ to protect against this kind of attack. The LDAP directory server
+ SHOULD log as much information as it can (such as client IP address)
+ whenever an account is locked, in order to be able to identify the
+ origin of the attack. Denying anonymous access to the LDAP directory
+ is also a way to restrict this kind of attack.
+
+ Returning certain status codes (such as passwordPolicyResponse.error
+ = accountLocked) allows a denial of service attacker to know that it
+ has successfully denied service to an account. Servers SHOULD
+ implement additional checks which return the same status when it is
+ sensed that some number of failed authentication requests has occured
+ on a single connection, or from a client address. Server
+ implementors are encouraged to invent other checks similar to this in
+ order to thwart this type of DoS attack.
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 37]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+13. IANA Considerations
+
+ <<<TBD>>>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 38]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+14. Acknowledgement
+
+ This document is based in part on prior work done by Valerie Chu from
+ Netscape Communications Corp, published as
+ draft-vchu-ldap-pwd-policy-00.txt (December 1998). Prasanta Behera
+ participated in early revisions of this document.
+
+15. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
+ AUTHorize Extension for Simple Challenge/Response",
+ RFC 2195, September 1997.
+
+ [RFC2222] Myers, J., "Simple Authentication and Security Layer
+ (SASL)", RFC 2222, October 1997.
+
+ [RFC2251] Wahl, M., Howes, T., and S. Kille, "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.
+
+ [RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a
+ SASL Mechanism", RFC 2831, May 2000.
+
+ [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation",
+ RFC 3062, February 2001.
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+ [RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory
+ Access Protocol (LDAP)", RFC 3672, December 2003.
+
+ [X680] International Telecommunications Union, "Abstract Syntax
+ Notation One (ASN.1): Specification of basic notation",
+ ITU-T Recommendation X.680, July 2002.
+
+ [X690] International Telecommunications Union, "Information
+ Technology - ASN.1 encoding rules: Specification of Basic
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 39]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ Encoding Rules (BER), Canonical Encoding Rules (CER) and
+ Distinguished Encoding Rules (DER)", ITU-T Recommendation
+ X.690, July 2002.
+
+
+Authors' Addresses
+
+ Jim Sermersheim
+ Novell, Inc
+ 1800 South Novell Place
+ Provo, Utah 84606
+ USA
+
+ Phone: +1 801 861-3088
+ Email: jimse at novell.com
+
+
+ Ludovic Poitou
+ Sun Microsystems
+ 180, Avenue de l'Europe
+ Zirst de Montbonnot, 38334 Saint Ismier cedex
+ France
+
+ Phone: +33 476 188 212
+ Email: ludovic.poitou at sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 40]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+Intellectual Property Statement
+
+ 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 at ietf.org.
+
+
+Disclaimer of Validity
+
+ 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.
+
+
+Copyright Statement
+
+ 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.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 41]
+
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-chu-ldap-csn-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-chu-ldap-csn-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-chu-ldap-csn-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,424 @@
+
+
+
+
+
+
+INTERNET-DRAFT Howard Y. Chu
+Intended Category: Standard Track Symas Corporation
+Expires in six months 1 December 2004
+
+
+ Change Sequence Numbers for LDAP
+ <draft-chu-ldap-csn-00.txt>
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with all
+ provisions of Section 10 of RFC2026.
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the 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 at ietf.org>. Please send editorial comments directly to the
+ author <Kurt at OpenLDAP.org>.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as ``work in progress.''
+
+ The list of current Internet-Drafts can be accessed at
+ <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
+ Internet-Draft Shadow Directories can be accessed at
+ <http://www.ietf.org/shadow.html>.
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+Abstract
+
+ This document describes the LDAP/X.500 Change Sequence Number 'CSN'
+ syntax and matching rules and associated attributes. CSNs are used
+ to impose a total ordering upon the sequence of updates applied
+ to a directory.
+
+
+
+
+Chu draft-chu-ldap-csn-00 [Page 1]
+
+INTERNET-DRAFT LDAP CSN 1 December 2004
+
+
+1. Background and Intended Use
+
+ In X.500 Directory Services [X.501], updates to a directory may need
+ to be distributed to multiple servers. The 'modifyTimeStamp' is already
+ defined for recording the time of an update, but it may be inadequate in
+ an environment where multiple servers with loosely synchronized clocks
+ are interoperating.
+
+ This document describes the 'CSN' syntax which augments a timestamp with
+ additional information to assist in coordinating updates among multiple
+ directory servers. This document describes the 'entryCSN' operational
+ attribute which carries the CSN of the last update applied to an entry
+ and also the 'contextCSN' operational attribute which carries the
+ greatest CSN of all updates applied to a directory context. Directory
+ clients and servers may use these attributes to assist in synchronizing
+ shadowed copies of directory information.
+
+ This document describes the 'csnMatch' and 'csnOrderingMatch' matching
+ rules corresponding to the 'CSN' syntax.
+
+ 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].
+
+ Schema definitions are provided using LDAP description formats
+ [RFC2252]. Definitions provided here are formatted (line wrapped) for
+ readability.
+
+
+2. CSN Schema Elements
+
+2.1 CSN Syntax
+
+ Values in this syntax are encoded according to the following BNF:
+
+ CSN = timestamp '#' operation-counter '#' replica-id
+
+ timestamp = <generalizedTimeString as specified in 6.14 of [RFC2252]>
+
+ operation-counter = 6hex-digit
+
+ replica-id = 2hex-digit
+
+ The timestamp SHALL use GMT and SHALL NOT include fractional seconds.
+
+ The operation-counter is set to zero at the start of each second, and
+ incremented by one for each update operation that occurs within that
+ second.
+
+ The replica-id is an identifier that represents a specific Replica in
+ a collection of cooperating servers.
+
+ The following is a LDAP syntax description [RFC2252] suitable for
+ publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.1 DESC 'CSN' )
+
+
+
+
+
+Chu draft-chu-ldap-csn-00 [Page 2]
+
+INTERNET-DRAFT LDAP CSN 1 December 2004
+
+
+2.2 'csnMatch' Matching Rule
+
+ The 'csnMatch' matching rule compares an asserted CSN with a stored
+ CSN for equality. Its semantics are same as the octetStringMatch
+ [X.520][RFC2252] matching rule.
+
+ The following is a LDAP matching rule description [RFC2252] suitable
+ for publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.2 NAME 'csnMatch'
+ SYNTAX IANA-ASSIGNED-OID.1 )
+
+
+2.3 'csnOrderingMatch' Matching Rule
+
+ The 'csnOrderingMatch' matching rule compares an asserted CSN
+ with a stored CSN for ordering. Its semantics are the same as the
+ octetStringOrderingMatch [X.520][RFC2252] matching rule.
+
+ The following is a LDAP matching rule description [RFC2252] suitable
+ for publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.3 NAME 'csnOrderingMatch'
+ SYNTAX IANA-ASSIGNED-OID.1 )
+
+
+2.4. 'entryCSN' attribute
+
+ The 'entryCSN' operational attribute provides the CSN of the last
+ update applied to the entry.
+
+ The following is a LDAP attribute type description [RFC2252] suitable
+ for publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.4 NAME 'entryCSN'
+ DESC 'CSN of the entry content'
+ EQUALITY csnMatch
+ ORDERING csnOrderingMatch
+
+
+
+Chu draft-chu-ldap-csn-00 [Page 3]
+
+INTERNET-DRAFT LDAP CSN 1 December 2004
+
+
+ SYNTAX IANA-ASSIGNED-OID.1
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ Servers SHALL assign a CSN to each entry upon its addition to the
+ directory and provide the entry's CSN as the value of the
+ 'entryCSN' operational attribute. The entryCSN attribute SHOULD be
+ updated upon every update of the entry.
+
+2.5. 'contextCSN' attribute
+
+ The 'contextCSN' operational attribute provides the greatest CSN of
+ all the updates applied to a context.
+
+ The following is a LDAP attribute type description [RFC2252] suitable
+ for publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.5 NAME 'contextCSN'
+ DESC 'the largest committed CSN of a context'
+ EQUALITY csnMatch
+ ORDERING csnOrderingMatch
+ SYNTAX IANA-ASSIGNED-OID.1
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ Servers SHALL record the greatest CSN of all updates applied to a
+ context in the root entry of the context.
+
+
+3. Security Considerations
+
+
+ General LDAP security considerations [RFC3377] apply.
+
+
+4. IANA Considerations
+
+4.1. Object Identifier Registration
+
+ It is requested that IANA register upon Standards Action an LDAP
+ Object Identifier for use in this technical specification.
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Howard Chu <hyc at symas.com>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the CSN schema elements
+
+
+4.2. Registration of the csnMatch descriptor
+
+ It is requested that IANA register upon Standards Action the LDAP
+ 'csnMatch' descriptor.
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): csnMatch
+ Object Identifier: IANA-ASSIGNED-OID.2
+ Person & email address to contact for further information:
+ Howard Chu <hyc at symas.com>
+ Usage: Matching Rule
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+
+
+Chu draft-chu-ldap-csn-00 [Page 4]
+
+INTERNET-DRAFT LDAP CSN 1 December 2004
+
+
+4.3. Registration of the csnOrderingMatch descriptor
+
+ It is requested that IANA register upon Standards Action the LDAP
+ 'csnOrderingMatch' descriptor.
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): csnOrderingMatch
+ Object Identifier: IANA-ASSIGNED-OID.3
+ Person & email address to contact for further information:
+ Howard Chu <hyc at symas.com>
+ Usage: Matching Rule
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+4.4. Registration of the entryCSN descriptor
+
+ It is requested that IANA register upon Standards Action the LDAP
+ 'entryCSN' descriptor.
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): entryCSN
+ Object Identifier: IANA-ASSIGNED-OID.4
+ Person & email address to contact for further information:
+ Howard Chu <hyc at symas.com>
+ Usage: Attribute Type
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+4.5. Registration of the contextCSN descriptor
+
+ It is requested that IANA register upon Standards Action the LDAP
+ 'contextCSN' descriptor.
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): contextCSN
+ Object Identifier: IANA-ASSIGNED-OID.5
+ Person & email address to contact for further information:
+ Howard Chu <hyc at symas.com>
+ Usage: Attribute Type
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+5. Acknowledgments
+
+ This document is based on prior work from the IETF LDUP working
+ group including the LDAP Replication Architecture [LDUPMODEL]
+ and the LDAP Content Synchronization Operation [LDUPSYNC].
+
+
+6. Author's Addresses
+
+ Howard Y. Chu
+ Symas Corporation
+ <hyc at symas.com>
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt at OpenLDAP.org>
+
+
+7. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+
+
+Chu draft-chu-ldap-csn-00 [Page 5]
+
+INTERNET-DRAFT LDAP CSN 1 December 2004
+
+
+ [RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [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(1997) (also ISO/IEC 8824-1:1998).
+
+ [LDUPSYNC] Zeilenga, K. and Choi, J-H "LDAP Content Synchronization
+ Operation", draft-zeilenga-ldup-sync-05.txt, a work in
+ progress.
+
+
+8. Informative References
+
+ [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
+ (also RFC 3383), September 2002.
+
+ [LDUPMODEL] Merrellls, J., Srinivasan, U., and Reed, E., "LDAP
+ Replication Architecture", draft-ietf-ldup-model-09.txt.
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+
+
+
+Chu draft-chu-ldap-csn-00 [Page 6]
+
+INTERNET-DRAFT LDAP CSN 1 December 2004
+
+
+ intellectual property or other rights that might be claimed to pertain
+ to the implementation or use of the technology described in this
+ document or the extent to which any license under such rights might or
+ might not be available; neither does it represent that it has made any
+ effort to identify any such rights. Information on the IETF's
+ procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such proprietary
+ rights by implementors or users of this specification can be obtained
+ from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implmentation may be prepared, copied, published and
+ distributed, in whole or in part, without restriction of any kind,
+ provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be followed,
+ or as required to translate it into languages other than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chu draft-chu-ldap-csn-00 [Page 7]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,1937 @@
+
+INTERNET-DRAFT Editor: R. Harrison
+draft-ietf-ldapbis-authmeth-19.txt Novell, Inc.
+Obsoletes: 2251, 2829, 2830 February 2006
+Intended Category: Standards Track
+
+
+
+
+
+
+
+ LDAP: Authentication Methods
+ and
+ Security Mechanisms
+
+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 becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ 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 Revision Working
+ Group mailing list <ietf-ldapbis at OpenLDAP.org>. Please send
+ editorial comments directly to the author
+ <roger_harrison at novell.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 as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+Abstract
+
+ This document describes authentication methods and security
+ mechanisms of the Lightweight Directory Access Protocol (LDAP).
+
+
+
+Harrison Expires August 2006 [Page 1]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ This document details establishment of Transport Layer Security
+ (TLS) using the StartTLS operation.
+
+ This document details the simple Bind authentication method
+ including anonymous, unauthenticated, and name/password mechanisms
+ and the Simple Authentication and Security Layer (SASL) Bind
+ authentication method including the EXTERNAL mechanism.
+
+ This document discusses various authentication and authorization
+ states through which a session to an LDAP server may pass and the
+ actions that trigger these state changes.
+
+ This document, together with other documents in the LDAP Technical
+ Specification (see section 1 of [Roadmap]), obsoletes RFC 2251, RFC
+ 2829 and RFC 2830.
+
+Table of Contents
+
+ 1. Introduction.....................................................3
+ 1.1. Relationship to Other Documents................................5
+ 1.2. Conventions....................................................6
+ 2. Implementation Requirements......................................7
+ 3. StartTLS Operation...............................................7
+ 3.1. TLS Establishment Procedures...................................7
+ 3.1.1. StartTLS Request Sequencing..................................8
+ 3.1.2. Client Certificate...........................................8
+ 3.1.3. Server Identity Check........................................8
+ 3.1.3.1. Comparison of DNS Names...................................10
+ 3.1.3.2. Comparison of IP Addresses................................10
+ 3.1.3.3. Comparison of other subjectName types.....................10
+ 3.1.4. Discovery of Resultant Security Level.......................10
+ 3.1.5. Refresh of Server Capabilities Information..................11
+ 3.2. Effect of TLS on Authorization State..........................11
+ 3.3. TLS Ciphersuites..............................................11
+ 4. Authorization State.............................................12
+ 5. Bind Operation..................................................13
+ 5.1. Simple Authentication Method..................................13
+ 5.1.1. Anonymous Authentication Mechanism of Simple Bind...........13
+ 5.1.2. Unauthenticated Authentication Mechanism of Simple Bind.....13
+ 5.1.3. Name/Password Authentication Mechanism of Simple Bind.......14
+ 5.2. SASL Authentication Method....................................15
+ 5.2.1. SASL Protocol Profile.......................................15
+ 5.2.1.1. SASL Service Name for LDAP................................15
+ 5.2.1.2. SASL Authentication Initiation and Protocol Exchange......15
+ 5.2.1.3. Optional Fields...........................................16
+ 5.2.1.4. Octet Where Negotiated Security Layers Take Effect........17
+ 5.2.1.5. Determination of Supported SASL Mechanisms................17
+ 5.2.1.6. Rules for Using SASL Layers...............................17
+ 5.2.1.7. Support for Multiple Authentications......................18
+ 5.2.1.8. SASL Authorization Identities.............................18
+ 5.2.2. SASL Semantics Within LDAP..................................19
+
+Harrison Expires August 2006 [Page 2]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ 5.2.3. SASL EXTERNAL Authentication Mechanism......................19
+ 5.2.3.1. Implicit Assertion........................................19
+ 5.2.3.2. Explicit Assertion........................................20
+ 6. Security Considerations.........................................20
+ 6.1. General LDAP Security Considerations..........................20
+ 6.2. StartTLS Security Considerations..............................21
+ 6.3. Bind Operation Security Considerations........................21
+ 6.3.1. Unauthenticated Mechanism Security Considerations...........21
+ 6.3.2. Name/Password Mechanism Security Considerations.............22
+ 6.3.3. Password-related Security Considerations....................22
+ 6.3.4. Hashed Password Security Considerations.....................23
+ 6.4.SASL Security Considerations...................................23
+ 6.5. Related Security Considerations...............................23
+ 7. IANA Considerations.............................................24
+ 8. Acknowledgments.................................................24
+ 9. Normative References............................................24
+ 10. Informative References.........................................25
+ Author's Address...................................................26
+ Appendix A. Authentication and Authorization Concepts..............26
+ A.1. Access Control Policy.........................................26
+ A.2. Access Control Factors........................................26
+ A.3. Authentication, Credentials, Identity.........................27
+ A.4. Authorization Identity........................................27
+ Appendix B. Summary of Changes.....................................27
+ B.1. Changes Made to RFC 2251......................................28
+ B.1.1. Section 4.2.1 (Sequencing of the Bind Request)..............28
+ B.1.2. Section 4.2.2 (Authentication and Other Security Services)..28
+ B.2. Changes Made to RFC 2829......................................28
+ B.2.1. Section 4 (Required security mechanisms)....................29
+ B.2.2. Section 5.1 (Anonymous authentication procedure)............29
+ B.2.3. Section 6 (Password-based authentication)...................29
+ B.2.4. Section 6.1 (Digest authentication).........................29
+ B.2.5. Section 6.2 ("simple" authentication choice with TLS).......29
+ B.2.6. Section 6.3 (Other authentication choices with TLS).........29
+ B.2.7. Section 7.1 (Certificate-based authentication with TLS).....30
+ B.2.8. Section 8 (Other mechanisms)................................30
+ B.2.9. Section 9 (Authorization identity)..........................30
+ B.2.10. Section 10 (TLS Ciphersuites)..............................30
+ B.3. Changes Made to RFC 2830: ....................................30
+ B.3.1. Section 3.6 (Server Identity Check).........................30
+ B.3.2. Section 3.7 (Refresh of Server Capabilities Information)....31
+ B.3.3. Section 5.2 (Effects of TLS on Authorization Identity)......31
+ B.3.4. Section 5.1.1 (TLS Closure Effects).........................31
+ Appendix C. Changes for draft-ldapbis-authmeth-19..................31
+ Intellectual Property Rights.......................................32
+ Full Copyright Statement...........................................33
+
+
+1. Introduction
+
+
+Harrison Expires August 2006 [Page 3]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ The Lightweight Directory Access Protocol (LDAP) [Roadmap] is a
+ powerful protocol for accessing directories. It offers means of
+ searching, retrieving and manipulating directory content and ways to
+ access a rich set of security functions.
+
+ It is vital that these security functions be interoperable among all
+ LDAP clients and servers on the Internet; therefore there has to be
+ a minimum subset of security functions that is common to all
+ implementations that claim LDAP conformance.
+
+ Basic threats to an LDAP directory service include (but are not
+ limited to):
+
+ (1) Unauthorized access to directory data via data-retrieval
+ operations.
+
+ (2) Unauthorized access to directory data by monitoring access of
+ others.
+
+ (3) Unauthorized access to reusable client authentication
+ information by monitoring access of others.
+
+ (4) Unauthorized modification of directory data.
+
+ (5) Unauthorized modification of configuration information.
+
+ (6) Denial of Service: Use of resources (commonly in excess) in a
+ manner intended to deny service to others.
+
+ (7) Spoofing: Tricking a user or 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
+ transport connection. Tricking a user or client into sending
+ privileged information to a hostile entity that appears to be
+ the directory server but is not. Tricking a directory server
+ into believing that information came from a particular client
+ when in fact it came from a hostile entity.
+
+ (8) Hijacking: An attacker seizes control of an established protocol
+ session.
+
+ Threats (1), (4), (5), (6), (7) are (8) are active attacks. Threats
+ (2) and (3) are passive attacks.
+
+ Threats (1), (4), (5) and (6) are due to hostile clients. Threats
+ (2), (3), (7) and (8) are due to hostile agents on the path between
+ client and server or hostile agents posing as a server, e.g., IP
+ spoofing.
+
+ LDAP offers the following security mechanisms:
+
+
+
+
+
+Harrison Expires August 2006 [Page 4]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ (1) Authentication by means of the Bind operation. The Bind
+ operation provides a simple method which supports anonymous,
+ unauthenticated, and name/password mechanisms, and the Simple
+ Authentication and Security Layer (SASL) method which supports a
+ wide variety of authentication mechanisms.
+
+ (2) Mechanisms to support vendor-specific access control facilities
+ (LDAP does not offer a standard access control facility).
+
+ (3) Data integrity service by means of security layers in Transport
+ Layer Security (TLS) or SASL mechanisms.
+
+ (4) Data confidentiality service by means of security layers in TLS
+ or SASL mechanisms.
+
+ (5) Server resource usage limitation by means of administrative
+ limits configured on the server.
+
+ (6) Server authentication by means of the TLS protocol or SASL
+ mechanisms.
+
+ LDAP may also be protected by means outside the LDAP protocol, e.g.,
+ with IP-level security [RFC4301].
+
+ Experience has shown that simply allowing implementations to pick
+ and choose the security mechanisms that will be implemented is not a
+ strategy that leads to interoperability. In the absence of
+ mandates, clients will continue to be written that do not support
+ any security function supported by the server, or worse, they will
+ only support mechanisms that provide inadequate security for most
+ circumstances.
+
+ It is desirable to allow clients to authenticate using a variety of
+ mechanisms including mechanisms where identities are represented as
+ distinguished names [X.501][Models] in string form [LDAPDN] or as
+ used in different systems (e.g., simple user names [RFC4013]).
+ Because some authentication mechanisms transmit credentials in plain
+ text form, and/or do not provide data security services and/or are
+ subject to passive attacks, it is necessary to ensure secure
+ interoperability by identifying a mandatory-to-implement mechanism
+ for establishing transport-layer security services.
+
+ The set of security mechanisms provided in LDAP and described in
+ this document is intended to meet the security needs for a wide
+ range of deployment scenarios and still provide a high degree of
+ interoperability among various LDAP implementations and deployments.
+
+1.1. Relationship to Other Documents
+
+ This document is an integral part of the LDAP Technical
+ Specification [Roadmap].
+
+
+
+
+Harrison Expires August 2006 [Page 5]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ This document, together with [Roadmap], [Protocol], and [Models],
+ obsoletes RFC 2251 in its entirety. Sections 4.2.1 (portions), and
+ 4.2.2 of RFC 2251 are obsoleted by this document. Appendix B.1
+ summarizes the substantive changes made to RFC 2251 by this document.
+
+ This document obsoletes RFC 2829 in its entirety. Appendix B.2
+ summarizes the substantive changes made to RFC 2829 by this document.
+
+ Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The
+ remainder of RFC 2830 is obsoleted by this document. Appendix B.3
+ summarizes the substantive changes made to RFC 2830 by this document.
+
+
+1.2. Conventions
+
+ The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT",
+ "MAY", and "OPTIONAL" in this document are to be interpreted as
+ described in RFC 2119 [RFC2119].
+
+ The term "user" represents any human or application entity which is
+ accessing the directory using a directory client. A directory
+ client (or client) is also known as a directory user agent (DUA).
+
+ The term "transport connection" refers to the underlying transport
+ services used to carry the protocol exchange, as well as
+ associations established by these services.
+
+ The term "TLS layer" refers to TLS services used in providing
+ security services, as well as associations established by these
+ services.
+
+ The term "SASL layer" refers to SASL services used in providing
+ security services, as well as associations established by these
+ services.
+
+ The term "LDAP message layer" refers to the LDAP Message (PDU)
+ services used in providing directory services, as well as
+ associations established by these services.
+
+ The term "LDAP session" refers to combined services (transport
+ connection, TLS layer, SASL layer, LDAP message layer) and their
+ associations.
+
+ In general, security terms in this document are used consistently
+ with the definitions provided in [RFC2828]. In addition, several
+ terms and concepts relating to security, authentication, and
+ authorization are presented in Appendix A of this document. While
+ the formal definition of these terms and concepts is outside the
+ scope of this document, an understanding of them is prerequisite to
+ understanding much of the material in this document. Readers who
+ are unfamiliar with security-related concepts are encouraged to
+ review Appendix A before reading the remainder of this document.
+
+
+
+Harrison Expires August 2006 [Page 6]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+2. Implementation Requirements
+
+ LDAP server implementations MUST support the anonymous
+ authentication mechanism of the simple Bind method (section 5.1.1).
+
+ LDAP implementations that support any authentication mechanism other
+ than the anonymous authentication mechanism of the simple Bind
+ method MUST support the name/password authentication mechanism of
+ the simple Bind method (section 5.1.3) and MUST be capable of
+ protecting this name/password authentication using TLS as
+ established by the StartTLS operation (section 3).
+
+ Implementations SHOULD disallow the use of the name/password
+ authentication mechanism by default when suitable data security
+ services are not in place, and MAY provide other suitable data
+ security services for use with this authentication mechanism.
+
+ Implementations MAY support additional authentication mechanisms.
+ Some of these mechanisms are discussed below.
+
+ LDAP server implementations SHOULD support client assertion of
+ authorization identity via the SASL EXTERNAL mechanism (section
+ 5.2.3).
+
+ LDAP server implementations that support no authentication mechanism
+ other than the anonymous mechanism of the simple bind method SHOULD
+ support use of TLS as established by the the StartTLS operation
+ (section 3). (Other servers MUST support TLS per the second
+ paragraph of this section.)
+
+ Implementations supporting TLS MUST support the
+ TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and SHOULD support the
+ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. Support for the
+ latter ciphersuite is recommended to encourage interoperability with
+ implementations conforming to earlier LDAP StartTLS specifications.
+
+
+3. StartTLS Operation
+
+ The Start Transport Layer Security (StartTLS) operation defined in
+ section 4.14 of [Protocol] provides the ability to establish TLS
+ [TLS] in an LDAP session.
+
+ The goals of using the TLS [TLS] protocol with LDAP are to ensure
+ data confidentiality and integrity, and to optionally provide for
+ authentication. TLS expressly provides these capabilities, although
+ the authentication services of TLS are available to LDAP only in
+ combination with the SASL EXTERNAL authentication method (see
+ section 5.2.3), and then only if the SASL EXTERNAL implementation
+ chooses to make use of the TLS credentials.
+
+
+3.1. TLS Establishment Procedures
+
+
+Harrison Expires August 2006 [Page 7]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ This section describes the overall procedures clients and servers
+ must follow for TLS establishment. These procedures take into
+ consideration various aspects of the TLS layer including discovery
+ of resultant security level and assertion of the client's
+ authorization identity.
+
+
+3.1.1. StartTLS Request Sequencing
+
+ A client may send the StartTLS extended request at any time after
+ establishing an LDAP session, except:
+
+ - when TLS is currently established on the session,
+ - when a multi-stage SASL negotiation is in progress on the
+ session, or
+ - when there are outstanding responses for operation requests
+ previously issued on the session.
+
+ As described in [Protocol] Section 4.14.1, a (detected) violation of
+ any of these requirements results in a return of the operationsError
+ resultCode.
+
+ Client implementers should ensure that they strictly follow these
+ operation sequencing requirements to prevent interoperability
+ issues. Operational experience has shown that violating these
+ requirements causes interoperability issues because there are race
+ conditions that prevent servers from detecting some violations of
+ these requirements due to factors such as server hardware speed and
+ network latencies.
+
+ There is no general requirement that the client have or have not
+ already performed a Bind operation (section 5) before sending a
+ StartTLS operation request, however where a client intends to
+ perform both a Bind operation and a StartTLS operation, it SHOULD
+ first perform the StartTLS operation so that the Bind request and
+ response messages are protected by the data security services
+ established by the StartTLS operation.
+
+
+3.1.2. Client Certificate
+
+ If an LDAP server requests or demands that a client provide a user
+ certificate during TLS negotiation and the client does not present a
+ suitable user certificate (e.g., one that can be validated), the
+ server may use a local security policy to determine whether to
+ successfully complete TLS negotiation.
+
+ If a client that has provided a suitable certificate subsequently
+ performs a Bind operation using the SASL EXTERNAL authentication
+ mechanism (section 5.2.3), information in the certificate may be
+ used by the server to identify and authenticate the client.
+
+
+3.1.3. Server Identity Check
+
+Harrison Expires August 2006 [Page 8]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+
+ In order to prevent man-in-the-middle attacks the client MUST verify
+ the server's identity (as presented in the server's Certificate
+ message). In this section, the client's understanding of the
+ server's identity (typically the identity used to establish the
+ transport connection) is called the "reference identity".
+
+ The client determines the type (e.g., DNS name or IP address) of the
+ reference identity and performs a comparison between the reference
+ identity and each subjectAltName value of the corresponding type
+ until a match is produced. Once a match is produced, the server's
+ identity has been verified and the server identity check is
+ complete. Different subjectAltName types are matched in different
+ ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of
+ various subjectAltName types.
+
+ The client may map the reference identity to a different type prior
+ to performing a comparison. Mappings may be performed for all
+ available subjectAltName types to which the reference identity can
+ be mapped, however the reference identity should only be mapped to
+ types for which the mapping is either inherently secure (e.g.,
+ extracting the DNS name from a URI to compare with a subjectAltName
+ of type dNSName) or for which the mapping is performed in a secure
+ manner (e.g., using DNSSec, or using user- (or admin-) configured
+ host-to-address/address-to-host lookup tables).
+
+ The server's identity may also be verified by comparing the
+ reference identity to the Common Name (CN) [Schema] value in the
+ leaf RDN of the subjectName field of the server's certificate. This
+ comparison is performed using the rules for comparison of DNS names
+ in section 3.1.3.1 below, with the exception that no wildcard
+ matching is allowed. Although the use of the Common Name value is
+ existing practice, it is deprecated and Certification Authorities
+ are encouraged to provide subjectAltName values instead. Note that
+ the TLS implementation may represent DNs in certificates according
+ to X.500 or other conventions. For example, some X.500
+ implementations order the RDNs in a DN using a left-to-right (most
+ significant to least significant) convention instead of LDAP's
+ right-to-left convention.
+
+ If the server identity check fails, user-oriented clients SHOULD
+ either notify the user (clients may give the user the opportunity to
+ continue with the LDAP session in this case) or close the transport
+ connection and indicate that the server's identity is suspect.
+ Automated clients SHOULD close the transport connection and then
+ return or log an error indicating that the server's identity is
+ suspect or both.
+
+ Beyond the server identity check 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 requested to provide.
+ The client may need to make use of local policy information in
+ making this determination.
+
+
+Harrison Expires August 2006 [Page 9]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+
+3.1.3.1. Comparison of DNS Names
+
+ If the reference identity is an internationalized domain name,
+ conforming implementations MUST convert it to the ASCII Compatible
+ Encoding (ACE) format as specified in section 4 of RFC 3490
+ [RFC3490] before comparison with subjectAltName values of type
+ dNSName. Specifically, conforming implementations MUST perform the
+ conversion operation specified in section 4 of RFC 3490 as follows:
+
+ * in step 1, the domain name SHALL be considered a "stored
+ string";
+ * in step 3, set the flag called "UseSTD3ASCIIRules";
+ * in step 4, process each label with the "ToASCII"
+ operation; and
+ * in step 5, change all label separators to U+002E (full
+ stop).
+
+ After performing the "to-ASCII" conversion, the DNS labels and names
+ MUST be compared for equality according to the rules specified in
+ section 3 of RFC3490.
+
+ The '*' (ASCII 42) wildcard character is allowed in subjectAltName
+ values of type dNSName and then only as the left-most (least
+ significant) DNS label in that value. This wildcard matches any
+ left-most DNS label in the server name. That is, the subject
+ *.example.com matches the server names a.example.com and
+ b.example.com but does not match example.com or a.b.example.com.
+
+
+3.1.3.2. Comparison of IP Addresses
+
+ When the reference identity is an IP address, the identity MUST be
+ converted to the "network byte order" octet string representation
+ [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the
+ octet string will contain exactly four octets. For IP Version 6, as
+ specified in RFC 2460, the octet string will contain exactly sixteen
+ octets. This octet string is then compared against subjectAltName
+ values of type iPAddress. A match occurs if the reference identity
+ octet string and value octet strings are identical.
+
+
+3.1.3.3. Comparison of other subjectName types
+
+ Client implementations MAY support matching against subjectAltName
+ values of other types as described in other documents.
+
+
+3.1.4. Discovery of Resultant Security Level
+
+
+
+
+
+
+Harrison Expires August 2006 [Page 10]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ After a TLS layer is established in an LDAP session, both parties
+ are to each independently decide whether or not to continue based on
+ local policy and the security level achieved. If either party
+ decides that the security level is inadequate for it to continue, it
+ SHOULD remove the TLS layer immediately after the TLS
+ (re)negotiation has completed (see [Protocol] section 4.14.3 and
+ section 3.2 below). Implementations may reevaluate the security
+ level at any time and, upon finding it inadequate, should remove the
+ TLS layer.
+
+
+3.1.5. Refresh of Server Capabilities Information
+
+ After a TLS layer is established in an LDAP session, the client
+ SHOULD discard or refresh all information about the server it
+ obtained prior to the initiation of the TLS negotiation and not
+ obtained through secure mechanisms. This protects against man-in-
+ the-middle attacks that may have altered any server capabilities
+ information retrieved prior to TLS layer installation.
+
+ The server may advertise different capabilities after installing a
+ TLS layer. In particular, the value of 'supportedSASLMechanisms'
+ may be different after a TLS layer has been installed (specifically,
+ the EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed
+ only after a TLS layer has been installed).
+
+
+3.2. Effect of TLS on Authorization State
+
+ The establishment, change, and/or closure of TLS may cause the
+ authorization state to move to a new state. This is discussed
+ further in Section 4.
+
+
+3.3. TLS Ciphersuites
+
+ Several issues should be considered when selecting TLS ciphersuites
+ that are appropriate for use in a given circumstance. These issues
+ include the following:
+
+ - The ciphersuite's ability to provide adequate confidentiality
+ protection for passwords and other data sent over the transport
+ connection. Client and server implementers should recognize
+ that some TLS ciphersuites provide no confidentiality protection
+ while other ciphersuites that do provide confidentiality
+ protection may be vulnerable to being cracked using brute force
+ methods, especially in light of ever-increasing CPU speeds that
+ reduce the time needed to successfully mount such attacks.
+
+ - Client and server implementers should carefully consider the
+ value of the password or data being protected versus the level
+ of confidentiality protection provided by the ciphersuite to
+ ensure that the level of protection afforded by the ciphersuite
+ is appropriate.
+
+Harrison Expires August 2006 [Page 11]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+
+ - The ciphersuite's vulnerability (or lack thereof) to man-in-the-
+ middle attacks. Ciphersuites vulnerable to man-in-the-middle
+ attacks 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 negligible.
+
+ - After a TLS negotiation (either initial or subsequent) is
+ completed, both protocol peers should independently verify that
+ the security services provided by the negotiated ciphersuite are
+ adequate for the intended use of the LDAP session. If not, the
+ TLS layer should be closed.
+
+
+4. Authorization State
+
+ Every LDAP session has an associated authorization state. This
+ state is comprised of numerous factors such as what (if any)
+ authorization state has been established, how it was established,
+ and what security services are in place. Some factors may be
+ determined and/or affected by protocol events (e.g., Bind, StartTLS,
+ or TLS closure), and some factors may be determined by external
+ events (e.g., time of day or server load).
+
+ While it is often convenient to view authorization state in
+ simplistic terms (as we often do in this technical specification)
+ such as "an anonymous state", it is noted that authorization systems
+ in LDAP implementations commonly involve many factors which
+ interrelate in complex manners.
+
+ Authorization in LDAP is a local matter. One of the key factors in
+ making authorization decisions is authorization identity. The Bind
+ operation defined in section 4.2 of [Protocol] and discussed further
+ in section 5 below allows information to be exchanged between the
+ client and server to establish an authorization identity for the
+ LDAP session. The Bind operation may also be used to move the LDAP
+ session to an anonymous authorization state (see section 5.1.1).
+
+ Upon initial establishment of the LDAP session, the session has an
+ anonymous authorization identity. Among other things this implies
+ that the client need not send a BindRequest in the first PDU of the
+ LDAP message layer. The client may send any operation request prior
+ to performing a Bind operation, and the server MUST treat it as if
+ it had been performed after an anonymous Bind operation (section
+ 5.1.1).
+
+ Upon receipt of a Bind request, the server immediately moves the
+ session to an anonymous authorization state. If the Bind request is
+ successful, the session is moved to the requested authentication
+ state with its associated authorization state. Otherwise, the
+ session remains in an anonymous state.
+
+
+
+
+Harrison Expires August 2006 [Page 12]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ It is noted that other events both internal and external to LDAP may
+ result in the authentication and authorization states being moved to
+ an anonymous one. For instance, the establishment, change or
+ closure of data security services may result in a move to an
+ anonymous state, or the user's credential information (e.g.,
+ certificate) may have expired. The former is an example of an event
+ internal to LDAP whereas the latter is an example of an event
+ external to LDAP.
+
+
+5. Bind Operation
+
+ The Bind operation ([Protocol] section 4.2) allows authentication
+ information to be exchanged between the client and server to
+ establish a new authorization state.
+
+ The Bind request typically specifies the desired authentication
+ identity. Some Bind mechanisms also allow the client to specify the
+ authorization identity. If the authorization identity is not
+ specified, the server derives it from the authentication identity in
+ an implementation-specific manner.
+
+ If the authorization identity is specified, the server MUST verify
+ that the client's authentication identity is permitted to assume
+ (e.g., proxy for) 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.
+
+
+5.1. Simple Authentication Method
+
+ The simple authentication method of the Bind Operation provides
+ three authentication mechanisms:
+
+ - An anonymous authentication mechanism (section 5.1.1).
+
+ - An unauthenticated authentication mechanism (section 5.1.2).
+
+ - A name/password authentication mechanism using credentials
+ consisting of a name (in the form of an LDAP distinguished name
+ [LDAPDN]) and a password (section 5.1.3).
+
+
+5.1.1. Anonymous Authentication Mechanism of Simple Bind
+
+ An LDAP client may use the anonymous authentication mechanism of the
+ simple Bind method to explicitly establish an anonymous
+ authorization state by sending a Bind request with a name value of
+ zero length and specifying the simple authentication choice
+ containing a password value of zero length.
+
+
+5.1.2. Unauthenticated Authentication Mechanism of Simple Bind
+
+
+Harrison Expires August 2006 [Page 13]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ An LDAP client may use the unauthenticated authentication mechanism
+ of the simple Bind method to establish an anonymous authorization
+ state by sending a Bind request with a name value (a distinguished
+ name in LDAP string form [LDAPDN] of non-zero length) and specifying
+ the simple authentication choice containing a password value of zero
+ length.
+
+ The distinguished name value provided by the client is intended to
+ be used for trace (e.g., logging) purposes only. The value is not
+ to be authenticated or otherwise validated (including verification
+ that the DN refers to an existing directory object). The value is
+ not to be used (directly or indirectly) for authorization purposes.
+
+ Unauthenticated Bind operations can have significant security issues
+ (see section 6.3.1). In particular, users intending to perform
+ Name/Password Authentication may inadvertently provide an empty
+ password and thus cause poorly implemented clients to request
+ Unauthenticated access. Clients SHOULD be implemented to require
+ user selection of the Unauthenticated Authentication Mechanism by
+ means other than user input of an empty password. Clients SHOULD
+ disallow an empty password input to a Name/Password Authentication
+ user interface. Additionally, Servers SHOULD by default fail
+ Unauthenticated Bind requests with a resultCode of
+ unwillingToPerform.
+
+
+5.1.3. Name/Password Authentication Mechanism of Simple Bind
+
+ An LDAP client may use the name/password authentication mechanism of
+ the simple Bind method to establish an authenticated authorization
+ state by sending a Bind request with a name value (a distinguished
+ name in LDAP string form [LDAPDN] of non-zero length) and specifying
+ the simple authentication choice containing an OCTET STRING password
+ value of non-zero length.
+
+ Servers that map the DN sent in the Bind request to a directory
+ entry with an associated set of one or more passwords used with this
+ mechanism will compare the presented password to that set of
+ passwords. The presented password is considered valid if it matches
+ any member of this set.
+
+ A resultCode of invalidDNSyntax indicates that the DN sent in the
+ name value is syntactically invalid. A resultCode of
+ invalidCredentials indicates that the DN is syntactically correct
+ but not valid for purposes of authentication, or the password is not
+ valid for the DN or the server otherwise considers the credentials
+ to be invalid. A resultCode of success indicates that the
+ credentials are valid and the server is willing to provide service
+ to the entity these credentials identify.
+
+ Server behavior is undefined for Bind requests specifying the
+ name/password authentication mechanism with a zero-length name value
+ and a password value of non-zero length.
+
+
+Harrison Expires August 2006 [Page 14]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ The name/password authentication mechanism of the simple Bind method
+ is not suitable for authentication in environments without
+ confidentiality protection.
+
+
+5.2. SASL Authentication Method
+
+ The sasl authentication method of the Bind Operation provides
+ facilities for using any SASL mechanism including authentication
+ mechanisms and other services (e.g., data security services).
+
+
+5.2.1. SASL Protocol Profile
+
+ LDAP allows authentication via any SASL mechanism [SASL]. As LDAP
+ includes native anonymous and name/password (plain text)
+ authentication methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN]
+ SASL mechanisms are typically not used with LDAP.
+
+ Each protocol that utilizes SASL services is required to supply
+ certain information profiling the way they are exposed through the
+ protocol ([SASL] section 4). This section explains how each of
+ these profiling requirements are met by LDAP.
+
+
+5.2.1.1. SASL Service Name for LDAP
+
+ The SASL service name for LDAP is "ldap", which has been registered
+ with the IANA as a SASL service name.
+
+
+5.2.1.2. SASL Authentication Initiation and Protocol Exchange
+
+ SASL authentication is initiated via a BindRequest message
+ ([Protocol] section 4.2) with the following parameters:
+
+ - The version is 3.
+ - The AuthenticationChoice is sasl.
+ - The mechanism element of the SaslCredentials sequence contains
+ the value of the desired SASL mechanism.
+ - The optional credentials field of the SaslCredentials sequence
+ MAY be used to provide an initial client response for
+ mechanisms that are defined to have the client send data first
+ (see [SASL] sections 3 and 5 ).
+
+
+
+
+
+
+
+
+
+
+
+Harrison Expires August 2006 [Page 15]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ In general, a SASL authentication protocol exchange consists of a
+ series of server challenges and client responses, the contents of
+ which are specific to and defined by the SASL mechanism. Thus for
+ some SASL authentication mechanisms, it may be necessary for the
+ client to respond to one or more server challenges by sending
+ BindRequest messages multiple times. A challenge is indicated by
+ the server sending a BindResponse message with the resultCode set to
+ saslBindInProgress. This indicates that the server requires the
+ client to send a new BindRequest message with the same SASL
+ mechanism to continue the authentication process.
+
+ To the LDAP message layer, these challenges and responses are opaque
+ binary tokens of arbitrary length. LDAP servers use the
+ serverSaslCreds field (an OCTET STRING) in a BindResponse message to
+ transmit each challenge. LDAP clients use the credentials field
+ (an OCTET STRING) in the SaslCredentials sequence of a BindRequest
+ message to transmit each response. Note that unlike some Internet
+ protocols where SASL is used, LDAP is not text based and does not
+ Base64-transform these challenge and response values.
+
+ Clients sending a BindRequest message with the sasl choice selected
+ SHOULD send a zero-length value in the name field. Servers
+ receiving a BindRequest message with the sasl choice selected SHALL
+ ignore any value in the name field.
+
+ A client may abort a SASL Bind negotiation by sending a BindRequest
+ message with a different value in the mechanism field of
+ SaslCredentials or with an AuthenticationChoice other than sasl.
+
+ If the client sends a BindRequest with the sasl mechanism field as
+ an empty string, the server MUST return a BindResponse with a
+ resultCode of authMethodNotSupported. This will allow the client to
+ abort a negotiation if it wishes to try again with the same SASL
+ mechanism.
+
+ The server indicates completion of the SASL challenge-response
+ exchange by responding with a BindResponse in which the resultCode
+ value is not saslBindInProgress.
+
+ The serverSaslCreds field in the BindResponse can be used to include
+ an optional challenge with a success notification for mechanisms
+ which are defined to have the server send additional data along with
+ the indication of successful completion.
+
+
+5.2.1.3. Optional Fields
+
+ As discussed above, LDAP provides an optional field for carrying an
+ initial response in the message initiating the SASL exchange and
+ provides an optional field for carrying additional data in the
+ message indicating outcome of the authentication exchange. As the
+ mechanism-specific content in these fields may be zero-length, SASL
+ requires protocol specifications to detail how an empty field is
+ distinguished from an absent field.
+
+Harrison Expires August 2006 [Page 16]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+
+ Zero-length initial response data is distinguished from no initial
+ response data in the initiating message, a BindRequest PDU, by the
+ presence of the SaslCredentials.credentials OCTET STRING (of length
+ zero) in that PDU. If the client does not intend to send an
+ initial response with the BindRequest initiating the SASL exchange,
+ it MUST omit the SaslCredentials.credentials OCTET STRING (rather
+ than including an zero-length OCTET STRING).
+
+ Zero-length additional data is distinguished from no additional
+ response data in the outcome message, a BindResponse PDU, by the
+ presence of the serverSaslCreds OCTET STRING (of length zero) in
+ that PDU. If a server does not intend to send additional data in
+ the BindResponse message indicating outcome of the exchange, the
+ server SHALL omit the serverSaslCreds OCTET STRING (rather than
+ including a zero-length OCTET STRING).
+
+
+5.2.1.4. Octet Where Negotiated Security Layers Take Effect
+
+ SASL layers take effect following the transmission by the server and
+ reception by the client of the final BindResponse in the SASL
+ exchange with a resultCode of success.
+
+ Once a SASL layer providing data integrity or confidentiality
+ services takes effect, the layer remains in effect until a new layer
+ is installed (i.e. at the first octet following the final
+ BindResponse of the Bind operation that caused the new layer to take
+ effect). Thus, an established SASL layer is not affected by a
+ failed or non-SASL Bind.
+
+
+5.2.1.5. Determination of Supported SASL Mechanisms
+
+ Clients may determine the SASL mechanisms a server supports by
+ reading the 'supportedSASLMechanisms' attribute from the root DSE
+ (DSA-Specific Entry) ([Models] section 5.1). The values of this
+ attribute, if any, list the mechanisms the server supports in the
+ current LDAP session state. LDAP servers SHOULD allow all clients--
+ even those with an anonymous authorization--to retrieve the
+ 'supportedSASLMechanisms' attribute of the root DSE both before and
+ after the SASL authentication exchange. The purpose of the latter
+ is to allow the client to detect possible downgrade attacks (see
+ section 6.4 and [SASL] section 6.1.2).
+
+ Because SASL mechanisms provide critical security functions, clients
+ and servers should be configurable to specify what mechanisms are
+ acceptable and allow only those mechanisms to be used. Both clients
+ and servers must confirm that the negotiated security level meets
+ their requirements before proceeding to use the session.
+
+
+5.2.1.6. Rules for Using SASL Layers
+
+
+Harrison Expires August 2006 [Page 17]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ Upon installing a SASL layer, the client SHOULD discard or refresh
+ all information about the server it obtained prior to the initiation
+ of the SASL negotiation and not obtained through secure mechanisms.
+
+ If a lower level security layer (such as TLS) is installed, any SASL
+ layer SHALL be layered on top of such security layers regardless of
+ the order of their negotiation. In all other respects, the SASL
+ layer and other security layers act independently, e.g., if both a
+ TLS layer and a SASL layer are in effect then removing the TLS layer
+ does not affect the continuing service of the SASL layer.
+
+
+5.2.1.7. Support for Multiple Authentications
+
+ LDAP supports multiple SASL authentications as defined in [SASL]
+ section 4.
+
+
+5.2.1.8. SASL Authorization Identities
+
+ Some SASL mechanisms allow clients to request a desired
+ authorization identity for the LDAP session ([SASL] section 3.4.
+ The decision to allow or disallow the current authentication
+ identity to have access to the requested authorization identity is a
+ matter of local policy. The authorization identity is a string of
+ UTF-8 [RFC3629] encoded [Unicode] characters corresponding to the
+ following ABNF [RFC2234bis] grammar:
+
+ authzId = dnAuthzId / uAuthzId
+
+ ; distinguished-name-based authz id
+ dnAuthzId = "dn:" distinguishedName
+
+ ; unspecified authorization id, UTF-8 encoded
+ uAuthzId = "u:" userid
+ userid = *UTF8 ; syntax unspecified
+
+ where the distinguishedName rule is defined in section 3 of [LDAPDN]
+ and the UTF8 rule is defined in section 1.4 of [Models].
+
+ The dnAuthzId choice is used to assert authorization identities in
+ the form of a distinguished name to be matched in accordance with
+ the distinguishedNameMatch matching rule [Syntaxes]. There is no
+ requirement that the asserted distinguishedName value be that of an
+ entry in the directory.
+
+
+
+
+
+
+
+
+
+
+Harrison Expires August 2006 [Page 18]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ The uAuthzId choice allows clients to assert an authorization
+ identity that is not in distinguished name form. The format of
+ userid is defined only as a sequence of UTF-8 [RFC3629] encoded
+ [Unicode] characters, and any further interpretation is a local
+ matter. For example, the userid could identify a user of a specific
+ directory service, be a login name or be an email address. A
+ uAuthzId SHOULD NOT be assumed to be globally unique. To compare
+ uAuthzID values, each uAuthzID value MUST be prepared as a "query"
+ string using [RFC4013] and then the two values are compared octet-
+ wise.
+
+ The above grammar is extensible. The authzId production may be
+ extended to support additional forms of identities. Each form is
+ distinguished by its unique prefix (see section 3.12 of [LDAPIANA]
+ for registration requirements).
+
+
+5.2.2. SASL Semantics Within LDAP
+
+ Implementers must take care to maintain the semantics of SASL
+ specifications when handling data that has different semantics in
+ the LDAP protocol.
+
+ For example, the SASL DIGEST-MD5 authentication mechanism [RFC2829]
+ utilizes an authentication identity and a realm which are
+ syntactically simple strings and semantically simple username and
+ realm values ([DIGEST-MD5] section 2.1). These values are not LDAP
+ DNs, and there is no requirement that they be represented or treated
+ as such.
+
+
+5.2.3. SASL EXTERNAL Authentication Mechanism
+
+ A client can use the SASL EXTERNAL [SASL] mechanism to request the
+ LDAP server to authenticate and establish a resulting authorization
+ identity using security credentials exchanged by a lower security
+ layer (such as by TLS authentication). If the client's
+ authentication credentials have not been established at a lower
+ security layer, the SASL EXTERNAL Bind MUST fail with a resultCode
+ of inappropriateAuthentication. Although this situation has the
+ effect of leaving the LDAP session in an anonymous state (section
+ 4), the state of any installed security layer is unaffected.
+
+ A client may either request that its authorization identity be
+ automatically derived from its authentication credentials exchanged
+ at a lower security layer or it may explicitly provide a desired
+ authorization identity. The former is known as an implicit
+ assertion, and the latter as an explicit assertion.
+
+
+5.2.3.1. Implicit Assertion
+
+
+
+
+Harrison Expires August 2006 [Page 19]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ An implicit authorization identity assertion is performed by
+ invoking a Bind request of the SASL form using the EXTERNAL
+ mechanism name that does not include the optional credentials field
+ (found within the SaslCredentials sequence in the BindRequest). The
+ server will derive the client's authorization identity from the
+ authentication identity supplied by a security layer (e.g., a public
+ key certificate used during TLS layer installation) according to
+ local policy. The underlying mechanics of how this is accomplished
+ are implementation specific.
+
+
+5.2.3.2. Explicit Assertion
+
+ An explicit authorization identity assertion is performed by
+ invoking a Bind request of the SASL form using the EXTERNAL
+ mechanism name that includes the credentials field (found within the
+ SaslCredentials sequence in the BindRequest). The value of the
+ credentials field (an OCTET STRING) is the asserted authorization
+ identity and MUST be constructed as documented in section 5.2.1.8.
+
+
+6. Security Considerations
+
+ Security issues are discussed throughout this document. The
+ unsurprising conclusion is that security is an integral and
+ necessary part of LDAP. This section discusses a number of LDAP-
+ related security considerations.
+
+
+6.1. General LDAP Security Considerations
+
+ LDAP itself provides no security or protection from accessing or
+ updating the directory by other means than through the LDAP
+ protocol, e.g., from inspection of server database files by database
+ administrators.
+
+ Sensitive data may be carried in almost any LDAP message and its
+ disclosure may be subject to privacy laws or other legal regulation
+ in many countries. Implementers should take appropriate measures to
+ protect sensitive data from disclosure to unauthorized entities.
+
+ A session on which the client has not established data integrity and
+ privacy services (e.g., via StartTLS, IPsec or a suitable SASL
+ mechanism) is subject to man-in-the-middle attacks to view and
+ modify information in transit. Client and server implementers
+ SHOULD take measures to protect sensitive data in the LDAP session
+ from these attacks by using data protection services as discussed in
+ this document. Clients and servers should provide the ability to be
+ configured to require these protections. A resultCode of
+ confidentialityRequired indicates that the server requires
+ establishment of (stronger) data confidentiality protection in order
+ to perform the requested operation.
+
+
+
+Harrison Expires August 2006 [Page 20]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ Access control should always be applied when reading sensitive
+ information or updating directory information.
+
+ Various security factors, including authentication and authorization
+ information and data security services may change during the course
+ of the LDAP session, or even during the performance of a particular
+ operation. Implementations should be robust in the handling of
+ changing security factors.
+
+
+6.2. StartTLS Security Considerations
+
+ All security gained via use of the StartTLS operation is gained by
+ the use of TLS itself. The StartTLS operation, on its own, does not
+ provide any additional security.
+
+ The level of security provided through the use of TLS depends
+ directly on both the quality of the TLS implementation used and the
+ style of usage of that implementation. Additionally, a man-in-the-
+ middle attacker can remove the StartTLS extended operation from the
+ 'supportedExtension' attribute of the root DSE. Both parties SHOULD
+ independently ascertain and consent to the security level achieved
+ once TLS is established and before beginning use of the TLS-
+ protected session. For example, the security level of the TLS layer
+ might have been negotiated down to plaintext.
+
+ Clients MUST either warn the user when the security level achieved
+ does not provide an acceptable level of data confidentiality and/or
+ data integrity protection, or be configurable to refuse to proceed
+ without an acceptable level of security.
+
+ As stated in section 3.1.2, a server may use a local security policy
+ to determine whether to successfully complete TLS negotiation.
+ Information in the user's certificate that is originated or verified
+ by the certification authority should be used by the policy
+ administrator when configuring the identification and authorization
+ policy.
+
+ Server implementers SHOULD allow server administrators to elect
+ whether and when data confidentiality and integrity are required, as
+ well as elect whether authentication of the client during the TLS
+ handshake is required.
+
+ Implementers should be aware of and understand TLS security
+ considerations as discussed in the TLS specification [TLS].
+
+
+6.3. Bind Operation Security Considerations
+
+ This section discusses several security considerations relevant to
+ LDAP authentication via the Bind operation.
+
+
+6.3.1. Unauthenticated Mechanism Security Considerations
+
+Harrison Expires August 2006 [Page 21]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+
+ Operational experience shows that clients can (and frequently do)
+ misuse the unauthenticated authentication mechanism of the simple
+ Bind method (see section 5.1.2). For example, a client program
+ might make a decision to grant access to non-directory information
+ on the basis of successfully completing a Bind operation. LDAP
+ server implementations may return a success response to an
+ unauthenticated Bind request. This may erroneously leave the client
+ with the impression that the server has successfully authenticated
+ the identity represented by the distinguished name when in reality,
+ an anonymous authorization state has been established. Clients that
+ use the results from a simple Bind operation to make authorization
+ decisions should actively detect unauthenticated Bind requests (by
+ verifying that the supplied password is not empty) and react
+ appropriately.
+
+
+6.3.2. Name/Password Mechanism Security Considerations
+
+ The name/password authentication mechanism of the simple Bind method
+ discloses the password to the server, which is an inherent security
+ risk. There are other mechanisms such as SASL DIGEST-MD5 [RFC2829]
+ that do not disclose the password to the server.
+
+
+6.3.3. Password-related Security Considerations
+
+ LDAP allows multi-valued password attributes. In systems where
+ entries are expected to have one and only one password,
+ administrative controls should be provided to enforce this behavior.
+
+ The use of clear text passwords and other unprotected authentication
+ credentials is strongly discouraged over open networks when the
+ underlying transport service cannot guarantee confidentiality. LDAP
+ implementations SHOULD NOT by default support authentication methods
+ using clear text passwords and other unprotected authentication
+ credentials unless the data on the session is protected using TLS or
+ other data confidentiality and data integrity protection.
+
+ The transmission of passwords in the clear--typically for
+ authentication or modification--poses a significant security risk.
+ This risk can be avoided by using SASL authentication [SASL]
+ mechanisms that do not transmit passwords in the clear or by
+ negotiating transport or session layer data confidentiality services
+ before transmitting password values.
+
+ To mitigate the security risks associated with the transfer of
+ passwords, a server implementation that supports any password-based
+ authentication mechanism that transmits passwords in the clear MUST
+ support a policy mechanism that at the time of authentication or
+ password modification, requires:
+
+ A TLS layer has been successfully installed.
+
+
+Harrison Expires August 2006 [Page 22]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ OR
+
+ Some other data confidentiality mechanism that protects the
+ password value from eavesdropping has been provided.
+
+ OR
+
+ The server returns a resultCode of confidentialityRequired for
+ the operation (i.e. name/password Bind with password value,
+ SASL Bind transmitting a password value in the clear, add or
+ modify including a userPassword value, etc.), even if the
+ password value is correct.
+
+ Server implementations may also want to provide policy mechanisms to
+ invalidate or otherwise protect accounts in situations where a
+ server detects that a password for an account has been transmitted
+ in the clear.
+
+
+6.3.4. Hashed Password Security Considerations
+
+ Some authentication mechanisms (e.g., DIGEST-MD5) transmit a hash of
+ the password value that may be vulnerable to offline dictionary
+ attacks. Implementers should take care to protect such hashed
+ password values during transmission using TLS or other
+ confidentiality mechanisms.
+
+
+6.4.SASL Security Considerations
+
+ Until data integrity service is installed on an LDAP session, an
+ attacker can modify the transmitted values of the
+ 'supportedSASLMechanisms' attribute response and thus downgrade the
+ list of available SASL mechanisms to include only the least secure
+ mechanism. To detect this type of attack, the client may retrieve
+ the SASL mechanisms the server makes available both before and after
+ data integrity service is installed on an LDAP session. If the
+ client finds that the integrity-protected list (the list obtained
+ after data integrity service was installed) contains a stronger
+ mechanism than those in the previously obtained list, the client
+ should assume the previously obtained list was modified by an
+ attacker. In this circumstance it is recommended that the client
+ close the underlying transport connection and then reconnect to
+ reestablish the session.
+
+
+6.5. Related Security Considerations
+
+ Additional security considerations relating to the various
+ authentication methods and mechanisms discussed in this document
+ apply and can be found in [SASL], [RFC4013], [StringPrep] and
+ [RFC3629].
+
+
+
+Harrison Expires August 2006 [Page 23]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+7. IANA Considerations
+
+ It is requested that the IANA update the LDAP Protocol Mechanism
+ registry to indicate that this document and [Protocol] provide the
+ definitive technical specification for the StartTLS
+ (1.3.6.1.4.1.1466.20037) extended operation.
+
+
+8. Acknowledgments
+
+ This document combines information originally contained in RFC 2251,
+ RFC 2829 and RFC 2830 which are products of the LDAP Extensions
+ (LDAPEXT) Working Group.
+
+ This document is a product of the IETF LDAP Revision (LDAPBIS)
+ working group.
+
+
+9. Normative References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn.]]
+
+ [LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String
+ Representation of Distinguished Names", draft-ietf-
+ ldapbis-dn-xx.txt, a work in progress.
+
+ [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-
+ ietf-ldapbis-bcp64-xx.txt, (a work in progress).
+
+ [Matching] Hoffman, Paul and Steve Hanna, "Matching Text Strings
+ in PKIX Certificates", draft-hoffman-pkix-stringmatch-
+ xx.txt, a work in progress.
+
+ [Models] Zeilenga, Kurt D. (editor), "LDAP: Directory
+ Information Models", draft-ietf-ldapbis-models-xx.txt,
+ a work in progress.
+
+ [Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf-
+ ldapbis-protocol-xx.txt, a work in progress.
+
+ [RFC791] Information Sciences Institute, "INTERNET PROTOCOL
+ DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION", RFC
+ 791, September 1981.
+
+ [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2234bis] Crocker, D., Ed. and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", draft-crocker-abnf-
+ rfc2234bis-xx, a work in progress.
+
+ [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6
+ (IPv6)", RFC 2460, December 1998.
+
+Harrison Expires August 2006 [Page 24]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+
+ [RFC3490] Falstrom, P., P. Hoffman, and A. Costello,
+ "Internationalizing Domain Names In Applications
+ (IDNA)", RFC 3490, March 2003.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 3629, STD 63, November 2003.
+
+ [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
+ Names and Passwords", RFC 4013, February 2005.
+
+ [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map",
+ draft-ietf-ldapbis-roadmap-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.
+
+ [Schema] Dally, K. (editor), "LDAP: User Schema", draft-ietf-
+ ldapbis-user-schema-xx.txt, a work in progress.
+
+ [StringPrep] M. Blanchet, "Preparation of Internationalized Strings
+ ('stringprep')", draft-hoffman-rfc3454bis-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.
+
+ [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version
+ 1.1", draft-ietf-tls-rfc2246-bis-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/).
+
+
+10. Informative References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn.]]
+
+ [ANONYMOUS] Zeilenga, K., "Anonymous SASL Mechanism", draft-
+ zeilenga-sasl-anon-xx.txt, a work in progress.
+
+ [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.
+
+
+Harrison Expires August 2006 [Page 25]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ [PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga-
+ sasl-plain-xx.txt, a work in progress.
+
+ [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May
+ 2000.
+
+ [RFC2829] Wahl, M. et al, "Authentication Methods for LDAP", RFC
+ 2829, May 2000.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
+
+Author's Address
+
+ Roger Harrison
+ Novell, Inc.
+ 1800 S. Novell Place
+ Provo, UT 84606
+ USA
+ +1 801 861 2642
+ roger_harrison at novell.com
+
+
+Appendix A. Authentication and Authorization Concepts
+
+ This appendix is non-normative.
+
+ This appendix 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.
+
+
+A.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. Security objects and
+ mechanisms, such as those described here, enable the expression of
+ access control policies and their enforcement.
+
+
+A.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 ([Protocol] section
+ 4.2). 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 transport connection via which the request is
+ transmitted, others (e.g., time of day) may be "environmental".
+
+
+Harrison Expires August 2006 [Page 26]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ Access control policies are expressed in terms of access control
+ factors. For example, "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.
+
+A.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 a new authorization state 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. X.509 certificates, Kerberos tickets, and simple
+ identity and password pairs are all examples of authentication
+ credential forms. Note that an authentication mechanism may
+ constrain the form of authentication identities used with it.
+
+
+A.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; for example, "entity
+ X can perform operation Y on resource Z."
+
+ The authorization identity of an LDAP session is often semantically
+ 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 [SASL]. 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.
+
+
+Appendix B. Summary of Changes
+
+ This appendix is non-normative.
+
+
+
+
+
+Harrison Expires August 2006 [Page 27]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ This appendix summarizes substantive changes made to RFC 2251, RFC
+ 2829 and RFC 2830. In addition to the specific changes detailed
+ below, the reader of this document should be aware that numerous
+ general editorial changes have been made to the original content
+ from the source documents. These changes include the following:
+
+ - The material originally found in RFC 2251 sections 4.2.1 and
+ 4.2.2, RFC 2829 (all sections except sections 2 and 4) and RFC
+ 2830 was combined into a single document
+
+ - The combined material was substantially reorganized and edited
+ to group related subjects, improve the document flow and clarify
+ intent.
+
+ - Changes were made throughout the text to align with definitions
+ of LDAP protocol layers and IETF security terminology.
+
+ - Substantial updates and additions were made to security
+ considerations from both documents based on current operational
+ experience.
+
+
+B.1. Changes Made to RFC 2251
+
+ This section summarizes the substantive changes made to sections
+ 4.2.1 and 4.2.2 of RFC 2251 by this document. Additional
+ substantive changes to section 4.2.1 of RFC 2251 are also documented
+ in [Protocol].
+
+
+B.1.1. Section 4.2.1 (Sequencing of the Bind Request)
+
+ - Paragraph 1: Removed the sentence, "If at any stage the client
+ wishes to abort the bind process it MAY unbind and then drop the
+ underlying connection." The Unbind operation still permits this
+ behavior, but it is not documented explicitly.
+
+ - Clarified that the session is moved to an anonymous state upon
+ receipt of the BindRequest PDU and that it is only moved to a
+ non-anonymous state if and when the Bind request is successful.
+
+
+B.1.2. Section 4.2.2 (Authentication and Other Security Services)
+
+ - RFC 2251 states that anonymous authentication MUST be performed
+ using the simple bind method. This specification defines the
+ anonymous authentication mechanism of the simple bind method and
+ requires all conforming implementations to support it. Other
+ authentication mechanisms producing anonymous authentication and
+ authorization state may also be implemented and used by
+ conforming implementations.
+
+
+B.2. Changes Made to RFC 2829
+
+Harrison Expires August 2006 [Page 28]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+
+ This section summarizes the substantive changes made to RFC 2829.
+
+
+B.2.1. Section 4 (Required security mechanisms)
+
+ - The name/password authentication mechanism (see section B.2.5
+ below) protected by TLS replaces the SASL DIGEST-MD5 mechanism
+ as LDAP's mandatory-to-implement password-based authentication
+ mechanism. Implementations are encouraged to continue
+ supporting SASL DIGEST-MD5 [RFC2829].
+
+
+B.2.2. Section 5.1 (Anonymous authentication procedure)
+
+ - Clarified that anonymous authentication involves a name value of
+ zero length and a password value of zero length. The
+ unauthenticated authentication mechanism was added to handle
+ simple Bind requests involving a name value with a non-zero
+ length and a password value of zero length.
+
+
+B.2.3. Section 6 (Password-based authentication)
+
+ - See section B.2.1.
+
+
+B.2.4. Section 6.1 (Digest authentication)
+
+ - As the SASL-DIGEST-MD5 mechanism is no longer mandatory to
+ implement, this section is now historical and was not included
+ in this document. RFC 2829 section 6.1 continues to document the
+ SASL DIGEST-MD5 authentication mechanism.
+
+
+B.2.5. Section 6.2 ("simple" authentication choice with TLS)
+
+ - Renamed the "simple" authentication mechanism to the
+ name/password authentication mechanism to better describe it.
+
+ - The use of TLS was generalized to align with definitions of LDAP
+ protocol layers. TLS establishment is now discussed as an
+ independent subject and is generalized for use with all
+ authentication mechanisms and other security layers.
+
+ - Removed the implication that the userPassword attribute is the
+ sole location for storage of password values to be used in
+ authentication. There is no longer any implied requirement for
+ how or where passwords are stored at the server for use in
+ authentication.
+
+
+B.2.6. Section 6.3 (Other authentication choices with TLS)
+
+
+Harrison Expires August 2006 [Page 29]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ - See section B.2.5.
+
+
+B.2.7. Section 7.1 (Certificate-based authentication with TLS)
+
+ - See section B.2.5.
+
+
+B.2.8. Section 8 (Other mechanisms)
+
+ - All SASL authentication mechanisms are explicitly allowed within
+ LDAP. Specifically, this means the SASL ANONYMOUS and SASL PLAIN
+ mechanisms are no longer precluded from use within LDAP.
+
+
+B.2.9. Section 9 (Authorization identity)
+
+ - Specified matching rules for dnAuthzID and uAuthzID values. In
+ particular, the DN value in the dnAuthzID form must be matched
+ using DN matching rules and the uAuthzID value MUST be prepared
+ using SASLprep rules before being compared octet-wise.
+
+ - Clarified that uAuthzID values should not be assumed to be
+ globally unique.
+
+
+B.2.10. Section 10 (TLS Ciphersuites)
+
+ - TLS Ciphersuite recommendations are no longer included in this
+ specification. Implementations must still support the
+ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.
+
+ - Clarified that anonymous authentication involves a name value of
+ zero length and a password value of zero length. The
+ unauthenticated authentication mechanism was added to handle
+ simple Bind requests involving a name value with a non-zero
+ length and a password value of zero length.
+
+
+B.3. Changes Made to RFC 2830:
+
+ This section summarizes the substantive changes made to sections 3
+ and 5 of RFC 2830. Readers should consult [Protocol] for summaries
+ of changes to other sections.
+
+
+B.3.1. Section 3.6 (Server Identity Check)
+
+
+
+
+
+
+
+
+Harrison Expires August 2006 [Page 30]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ - Substantially updated the server identity check algorithm to
+ ensure that it is complete and robust. In particular, the use
+ of all relevant values in the subjectAltName and the subjectName
+ fields are covered by the algorithm and matching rules are
+ specified for each type of value. Mapped (derived) forms of the
+ server identity may now be used when the mapping is performed in
+ a secure fashion.
+
+
+B.3.2. Section 3.7 (Refresh of Server Capabilities Information)
+
+ - Clients are no longer required to always refresh information
+ about server capabilities following TLS establishment to allow
+ for situations where this information was obtained through a
+ secure mechanism.
+
+
+B.3.3. Section 5.2 (Effects of TLS on Authorization Identity)
+
+ - Establishing a TLS layer on an LDAP session may now cause the
+ authorization state of the LDAP session to change.
+
+
+B.3.4. Section 5.1.1 (TLS Closure Effects)
+
+ - Closing a TLS layer on an LDAP session changes the
+ authentication and authorization state of the LDAP session based
+ on local policy. Specifically, this means that implementations
+ are not required to to change the authentication and
+ authorization states to anonymous upon TLS closure.
+
+
+Appendix C. Changes for draft-ldapbis-authmeth-19
+
+ [[Note to RFC Editor: Please remove this appendix upon publication
+ of this Internet-Draft as an RFC.]]
+
+ This appendix is non-normative.
+
+ This appendix summarizes changes made in this revision of the
+ document.
+
+ General
+
+ - This draft has addressed all issues raised for the -18 version.
+
+ - Several minor edits for clarity and to remove typos based on
+ feedback from WG, IETF and IESG reviews.
+
+ Abstract
+ - Added statement regarding RFCs obsoleted by this document.
+
+ Section 2
+
+
+Harrison Expires August 2006 [Page 31]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ - Changed mandatory-to-implement TLS ciphersuite from
+ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA to
+ TLS_RSA_WITH_3DES_EDE_CBC_SHA based on IESG recommendation and
+ WG consensus.
+
+ Section 5.2.1.5
+ - Clarified that 'supportedSASLMechanisms' should be retrievable
+ by all clients both before and after SASL negotiation to allow
+ detection of mechanism downgrade attacks.
+
+ Section 5.2.1.6
+ - Changed wording to reflect the fact that SASL layers cannot be
+ uninstalled from the session.
+
+ Section 5.2.3
+ - Removed reference to IPsec as a source of authorization identity.
+
+ Section 6.2
+ - When TLS layer does not provide an acceptable level of security
+ client MUST warn the user or refuse to proceed. (This was
+ changed from SHOULD based on IESG recommendation and WG
+ consensus.)
+
+ - Added a security consideration regarding the proper usage of
+ information found in the client certificate.
+
+ Section 6.4
+ - Added a new section on SASL security considerations that
+ discusses SASL mechanism downgrade attacks.
+
+ Section 10
+ - Replaced references to RFC 2401 with RFC 4301.
+
+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.
+
+
+
+
+
+Harrison Expires August 2006 [Page 32]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ 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 at ietf.org.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison Expires August 2006 [Page 33]
+
\ No newline at end of file
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-bcp64-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-bcp64-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-bcp64-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: BCP OpenLDAP Foundation
+Expires in six months 23 January 2006
+Obsoletes: RFC 3383
+
+
+ IANA Considerations for LDAP
+ <draft-ietf-ldapbis-bcp64-06.txt>
+
+
+
+Status of Memo
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as a Best Current Practice
+ document. This document is intended to replace RFC 3383.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Revision Working Group
+ (LDAPBIS) mailing list <ietf-ldapbis at openldap.org>. Please send
+ editorial comments directly to the document editor
+ <Kurt at 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 IANA Considerations for LDAP [Page 1]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+Abstract
+
+ This document provides procedures for registering extensible elements
+ of Lightweight Directory Access Protocol (LDAP). The document also
+ provides guidelines to Internet Assigned Numbers Authority (IANA)
+ describing conditions under which new values can be assigned.
+
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol [Roadmap] (LDAP) is an
+ extensible protocol. LDAP supports:
+
+ - addition of new operations,
+ - extension of existing operations, and
+ - extensible schema.
+
+ This document details procedures for registering values of used to
+ unambiguously identify extensible elements of the protocol including:
+
+ - LDAP message types;
+ - LDAP extended operations and controls;
+ - LDAP result codes;
+ - LDAP authentication methods;
+ - LDAP attribute description options; and
+ - Object Identifier descriptors.
+
+ These registries are maintained by the Internet Assigned Numbers
+ Authority (IANA).
+
+ In addition, this document provides guidelines to IANA describing the
+ conditions under which new values can be assigned.
+
+ This document replaces RFC 3383.
+
+
+2. Terminology and Conventions
+
+ This section details terms and conventions used in this document.
+
+
+2.1. Policy Terminology
+
+ The terms "IESG Approval", "Standards Action", "IETF Consensus",
+ "Specification Required", "First Come First Served", "Expert Review",
+ and "Private Use" are used as defined in BCP 26 [RFC2434].
+
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 2]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+2.2. Requirement 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 case, "the specification" as used by BCP 14 refers to the
+ processing of protocols being submitted to the IETF standards
+ process.
+
+
+2.3. Common ABNF Productions
+
+ A number of syntaxes in this document are described using ABNF
+ [ABNF]. These syntaxes rely on the following common productions:
+
+ ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
+ LDIGIT = %x31-39 ; "1"-"9"
+ DIGIT = %x30 / LDIGIT ; "0"-"9"
+ HYPHEN = %x2D ; "-"
+ DOT = %x2E ; "."
+ number = DIGIT / ( LDIGIT 1*DIGIT )
+ keychar = ALPHA / DIGIT / HYPHEN
+ leadkeychar = ALPHA
+ keystring = leadkeychar *keychar
+
+ A keyword is a case-insensitive string of UTF-8 [RFC3629] encoded
+ Unicode [Unicode] restricted to the <keystring> production.
+
+
+3. IANA Considerations for LDAP
+
+ This section details each kind of protocol value which can be
+ registered and provides IANA guidelines on how to assign new values.
+
+ IANA may reject obviously bogus registrations.
+
+ LDAP values specified in RFCs MUST be registered. Other LDAP values,
+ except those in private-use name spaces, SHOULD be registered. RFCs
+ SHOULD NOT reference, use, or otherwise recognize unregistered LDAP
+ values.
+
+
+3.1. Object Identifiers
+
+ Numerous LDAP schema and protocol elements are identified by Object
+ Identifiers (OIDs) [X.680]. Specifications which assign OIDs to
+ elements SHOULD state who delegated the OIDs for its use.
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 3]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ For IETF developed elements, specifications SHOULD use OIDs under
+ "Internet Directory Numbers" (1.3.6.1.1.x). For elements developed
+ by others, any properly delegated OID can be used, including those
+ under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private
+ Enterprise Numbers" (1.3.6.1.4.1.x).
+
+ Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert
+ Review with Specification Required. Only one OID per specification
+ will be assigned. The specification MAY then assign any number of
+ OIDs within this arc without further coordination with IANA.
+
+ Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by
+ IANA <http://www.iana.org/cgi-bin/enterprise.pl>. Practices for IANA
+ assignment of Internet Private Enterprise Numbers is detailed in RFC
+ 2578 [RFC2578].
+
+ To avoid interoperability problems between early implementations of a
+ "work in progress" and implementations of the published specification
+ (e.g., the RFC), experimental OIDs SHOULD be used in "works in
+ progress" and early implementations. OIDs under the Internet
+ Experimental OID arc (1.3.6.1.3.x) may be used for this purpose.
+ Practices for IANA assignment of these Internet Experimental numbers
+ is detailed in RFC 2578 [RFC2578]
+
+
+3.2 Protocol Mechanisms
+
+ LDAP provides a number of Root DSE attributes for discovery of
+ protocol mechanisms identified by OIDs, including the
+ supportedControl, supportedExtension, and supportedFeatures
+ attributes [Models],
+
+ A registry of OIDs used for discover of protocol mechanisms is
+ provided to allow implementors and others to locate the technical
+ specification for these protocol mechanisms. Future specifications
+ of additional Root DSE attributes holding values identifying protocol
+ mechanisms MAY extend this registry for their values.
+
+ Protocol Mechanisms are registered on a First Come First Served
+ basis.
+
+
+3.3 LDAP Syntaxes
+
+ This registry provides a listing of LDAP syntaxes [Models]. Each
+ LDAP syntax is identified by an object identifier (OID). This
+ registry is provided to allow implementors and others to locate the
+ technical specification describing a particular LDAP Syntax.
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 4]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ LDAP Syntaxes are registered on a First Come First Served with
+ Specification Required basis.
+
+ Note: unlike object classes, attribute types and various other kinds
+ of schema elements, descriptors are not used in LDAP to identify LDAP
+ Syntaxes.
+
+
+3.4. Object Identifier Descriptors
+
+ LDAP allows short descriptive names (or descriptors) to be used
+ instead of a numeric Object Identifier to identify select protocol
+ extensions [Protocol], schema elements [Models], LDAP URL [LDAPURL]
+ extensions, and other objects.
+
+ While the protocol allows the same descriptor to refer to different
+ object identifiers in certain cases and the registry supports
+ multiple registrations of the same descriptor (each indicating a
+ different kind of schema element and different object identifier),
+ multiple registrations of the same descriptor are to be avoided. All
+ such multiple registration requests require Expert Review.
+
+ Descriptors are restricted to strings of UTF-8 encoded Unicode
+ characters restricted by the following ABNF:
+
+ name = keystring
+
+ Descriptors are case-insensitive.
+
+ Multiple names may be assigned to a given OID. For purposes of
+ registration, an OID is to be represented in numeric OID form (e.g.,
+ 1.1.0.23.40) conforming to the ABNF:
+
+ numericoid = number 1*( DOT number )
+
+ While the protocol places no maximum length restriction upon
+ descriptors, they should be short. Descriptors longer than 48
+ characters may be viewed as too long to register.
+
+ A value ending with a hyphen ("-") reserves all descriptors which
+ start with that value. For example, the registration of the option
+ "descrFamily-" reserves all options which start with "descrFamily-"
+ for some related purpose.
+
+ Descriptors beginning with "x-" are for Private Use and cannot be
+ registered.
+
+ Descriptors beginning with "e-" are reserved for experiments and will
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 5]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ be registered on a First Come First Served basis.
+
+ All other descriptors require Expert Review to be registered.
+
+ The registrant need not "own" the OID being named.
+
+ The OID name space is managed by The ISO/IEC Joint Technical
+ Committee 1 - Subcommittee 6.
+
+
+3.5. AttributeDescription Options
+
+ An AttributeDescription [Models] can contain zero or more options
+ specifying additional semantics. An option SHALL be restricted to a
+ string UTF-8 encoded Unicode characters limited by the following
+ ABNF:
+
+ option = keystring
+
+ Options are case-insensitive.
+
+ While the protocol places no maximum length restriction upon option
+ strings, they should be short. Options longer than 24 characters may
+ be viewed as too long to register.
+
+ Values ending with a hyphen ("-") reserve all option names which
+ start with the name. For example, the registration of the option
+ "optionFamily-" reserves all options which start with "optionFamily-"
+ for some related purpose.
+
+ Options beginning with "x-" are for Private Use and cannot be
+ registered.
+
+ Options beginning with "e-" are reserved for experiments and will be
+ registered on a First Come First Served basis.
+
+ All other options require Standards Action or Expert Review with
+ Specification Required to be registered.
+
+
+3.6. LDAP Message Types
+
+ Each protocol message is encapsulated in an LDAPMessage envelope
+ [Protocol]. The protocolOp CHOICE indicates the type of message
+ encapsulated. Each message type consists of an ASN.1 identifier in
+ the form of a keyword and a non-negative choice number. The choice
+ number is combined with the class (APPLICATION) and data type
+ (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 6]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ encoding. The choice numbers for existing protocol messages are
+ implicit in the protocol's ASN.1 defined in [Protocol].
+
+ New values will be registered upon Standards Action.
+
+ Note: LDAP provides extensible messages which reduces, but does not
+ eliminate, the need to add new message types.
+
+
+3.7. LDAP Authentication Method
+
+ The LDAP Bind operation supports multiple authentication methods
+ [Protocol]. Each authentication choice consists of an ASN.1
+ identifier in the form of a keyword and a non-negative integer.
+
+ The registrant SHALL classify the authentication method usage using
+ one of the following terms:
+
+ COMMON - method is appropriate for common use on the
+ Internet,
+ LIMITED USE - method is appropriate for limited use,
+ OBSOLETE - method has been deprecated or otherwise found to
+ be inappropriate for any use.
+
+ Methods without publicly available specifications SHALL NOT be
+ classified as COMMON. New registrations of class OBSOLETE cannot be
+ registered.
+
+ New authentication method integers in the range 0-1023 require
+ Standards Action to be registered. New authentication method
+ integers in the range 1024-4095 require Expert Review with
+ Specification Required. New authentication method integers in the
+ range 4096-16383 will be registered on a First Come First Served
+ basis. Keywords associated with integers in the range 0-4095 SHALL
+ NOT start with "e-" or "x-". Keywords associated with integers in
+ the range 4096-16383 SHALL start with "e-". Values greater than or
+ equal to 16384 and keywords starting with "x-" are for Private Use
+ and cannot be registered.
+
+ Note: LDAP supports Simple Authentication and Security Layers [SASL]
+ as an authentication choice. SASL is an extensible
+ authentication framework.
+
+
+3.8. LDAP Result Codes
+
+ LDAP result messages carry an resultCode enumerated value to indicate
+ the outcome of the operation [Protocol]. Each result code consists
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 7]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ of a ASN.1 identifier in the form of a keyword and a non-negative
+ integer.
+
+ New resultCodes integers in the range 0-1023 require Standards Action
+ to be registered. New resultCode integers in the range 1024-4095
+ require Expert Review with Specification Required. New resultCode
+ integers in the range 4096-16383 will be registered on a First Come
+ First Served basis. Keywords associated with integers in the range
+ 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with
+ integers in the range 4096-16383 SHALL start with "e-". Values
+ greater than or equal to 16384 and keywords starting with "x-" are
+ for Private Use and cannot be registered.
+
+
+3.9. LDAP Search Scope
+
+ LDAP SearchRequest messages carry a scope enumerated value to
+ indicate the extend of search within the DIT [Protocol] Each search
+ value consists of a ASN.1 identifier in the form of a keyword and a
+ non-negative integer.
+
+ New scope integers in the range 0-1023 require Standards Action to be
+ registered. New scope integers in the range 1024-4095 require Expert
+ Review with Specification Required. New scope integers in the range
+ 4096-16383 will be registered on a First Come First Served basis.
+ Keywords associated with integers in the range 0-4095 SHALL NOT start
+ with "e-" or "x-". Keywords associated with integers in the range
+ 4096-16383 SHALL start with "e-". Values greater than or equal to
+ 16384 and keywords starting with "x-" are for Private Use and cannot
+ be registered.
+
+
+3.10. LDAP Filter Choice
+
+ LDAP filters are used in making assertions against an object
+ represented in the directory [Protocol]. The Filter CHOICE indicates
+ a type of assertion. Each Filter CHOICE consists of an ASN.1
+ identifier in the form of a keyword and a non-negative choice number.
+ The choice number is combined with the class (APPLICATION) and data
+ type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the
+ message's encoding.
+
+ Note: LDAP provides the extensibleMatching choice which reduces, but
+ does not eliminate, the need to add new filter choices.
+
+
+3.11. LDAP ModifyRequest Operation Type
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 8]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ The LDAP ModifyRequest carries a sequence of modification operations
+ [Protocol]. Each kind (e.g., add, delete, replace) of operation is
+ consists of a ASN.1 identifier in the form of a keyword and a
+ non-negative integer.
+
+ New operation type integers in the range 0-1023 require Standards
+ Action to be registered. New operation type integers in the range
+ 1024-4095 require Expert Review with Specification Required. New
+ operation type integers in the range 4096-16383 will be registered on
+ a First Come First Served basis. Keywords associated with integers
+ in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords
+ associated with integers in the range 4096-16383 SHALL start with
+ "e-". Values greater than or equal to 16384 and keywords starting
+ with "x-" are for Private Use and cannot be registered.
+
+
+3.12. LDAP authzId Prefixes
+
+ Authorization Identities in LDAP are strings conforming to the
+ <authzId> production [AuthMeth]. This production is extensible.
+ Each new specific authorization form is identified by a prefix string
+ conforming to the following ABNF:
+
+ prefix = keystring COLON
+ COLON = %x3A ; COLON (":" U+003A)
+
+ Prefixes are case-insensitive.
+
+ While the protocol places no maximum length restriction upon prefix
+ strings, they should be short. Prefixes longer than 12 characters
+ may be viewed as too long to register.
+
+ Prefixes beginning with "x-" are for Private Use and cannot be
+ registered.
+
+ Prefixes beginning with "e-" are reserved for experiments and will be
+ registered on a First Come First Served basis.
+
+ All other prefixes require Standards Action or Expert Review with
+ Specification Required to be registered.
+
+
+3.13. Directory Systems Names
+
+ The IANA-maintained "Directory Systems Names" registry [IANADSN] of
+ valid keywords for well known attributes was used in the LDAPv2
+ string representation of a distinguished name [RFC1779]. LDAPv2 is
+ now Historic [RFC3494].
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 9]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ Directory systems names are not known to be used in any other
+ context. LDAPv3 [LDAPDN] uses Object Identifier Descriptors [Section
+ 3.2] (which have a different syntax than directory system names).
+
+ New Directory System Names will no longer be accepted. For
+ historical purposes, the current list of registered names should
+ remain publicly available.
+
+
+4. Registration Procedure
+
+ The procedure given here MUST be used by anyone who wishes to use a
+ new value of a type described in Section 3 of this document.
+
+ The first step is for the requester to fill out the appropriate form.
+ Templates are provided in Appendix A.
+
+ If the policy is Standards Action, the completed form SHOULD be
+ provided to the IESG with the request for Standards Action. Upon
+ approval of the Standards Action, the IESG SHALL forward the request
+ (possibly revised) to IANA. The IESG SHALL be viewed as the owner of
+ all values requiring Standards Action.
+
+ If the policy is Expert Review, the requester SHALL post the
+ completed form to the <directory at apps.ietf.org> mailing list for
+ public review. The review period is two (2) weeks. If a revised
+ form is later submitted, the review period is restarted. Anyone may
+ subscribe to this list by sending a request to
+ <directory-request at apps.ietf.org>. During the review, objections may
+ be raised by anyone (including the Expert) on the list. After
+ completion of the review, the Expert, based upon public comments,
+ SHALL either approve the request and forward it to the IANA OR deny
+ the request. In either case, the Expert SHALL promptly notify the
+ requester of the action. Actions of the Expert may be appealed
+ [RFC2026]. The Expert is appointed by Applications Area Director(s).
+ The requester is viewed as the owner of values registered under
+ Expert Review.
+
+ If the policy is First Come First Served, the requester SHALL submit
+ the completed form directly to the IANA: <iana at iana.org>. The
+ requester is viewed as the owner of values registered under First
+ Come First Served.
+
+ Neither the Expert nor IANA will take position on the claims of
+ copyright or trademarks issues regarding completed forms.
+
+ Prior to submission of the Internet Draft (I-D) to the RFC Editor but
+ after IESG review and tentative approval, the document editor SHOULD
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 10]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ revise the I-D to use registered values.
+
+
+5. Registration Maintenance
+
+ This section discusses maintenance of registrations.
+
+
+5.1. Lists of Registered Values
+
+ IANA makes lists of registered values readily available to the
+ Internet community on their web site: <http://www.iana.org/>.
+
+
+5.2. Change Control
+
+ The registration owner MAY update the registration subject to the
+ same constraints and review as with new registrations. In cases
+ where the owner is not unable or unwilling to make necessary updates,
+ the IESG MAY assume ownership in order to update the registration.
+
+
+5.3. Comments
+
+ For cases where others (anyone other than the owner) have significant
+ objections to the claims in a registration and the owner does not
+ agree to change the registration, comments MAY be attached to a
+ registration upon Expert Review. For registrations owned by the
+ IESG, the objections SHOULD be addressed by initiating a request for
+ Expert Review.
+
+ The form to these requests is ad hoc, but MUST include the specific
+ objections to be reviewed and SHOULD contain (directly or by
+ reference) materials supporting the objections.
+
+
+6. Security Considerations
+
+ The security considerations detailed in BCP 26 [RFC2434] are
+ generally applicable to this document. Additional security
+ considerations specific to each name space are discussed in Section 3
+ where appropriate.
+
+ Security considerations for LDAP are discussed in documents
+ comprising the technical specification [Roadmap].
+
+
+7. Acknowledgment
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 11]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ This document is a product of the IETF LDAP Revision (LDAPBIS)
+ Working Group (WG). This document is a revision of RFC 3383, also a
+ product of the LDAPBIS WG.
+
+ This document includes text borrowed from "Guidelines for Writing an
+ IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and
+ Harald Alvestrand.
+
+
+8. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt at 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
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9 (also RFC 2026), October 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26 (also RFC
+ 2434), October 1998.
+
+ [RFC2578] K. McCloghrie, D. Perkins, J. Schoenwaelder, "Structure
+ of Management Information Version 2 (SMIv2)", RFC 2578
+ (STD: 58), April 1999.
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 3629 (also STD 63), November 2003.
+
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 12]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
+ Connection Level Security Mechanisms",
+ draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
+
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
+
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+ [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
+ draft-ietf-ldapbis-url-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/).
+
+ [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).
+
+
+9.2. Informative References
+
+ [RFC1779] Kille, S., "A String Representation of Distinguished
+ Names", RFC 1779, March 1995.
+
+ [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
+ version 2 (LDAPv2) to Historic Status", RFC 3494, March
+ 2003.
+
+ [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
+
+ [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-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.
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 13]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ [IANADSN] IANA, "Directory Systems Names",
+ http://www.iana.org/assignments/directory-system-names.
+
+
+Appendix A. Registration Templates
+
+ This appendix provides registration templates for registering new
+ LDAP values. Note that more than one value may be requested by
+ extending the template by listing multiple values, or through use of
+ tables.
+
+
+A.1. LDAP Object Identifier Registration Template
+
+ Subject: Request for LDAP OID Registration
+
+ Person & email address to contact for further information:
+
+ Specification: (I-D)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.2. LDAP Protocol Mechanism Registration Template
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+
+ Object Identifier:
+
+ Description:
+
+ Person & email address to contact for further information:
+
+ Usage: (One of Control or Extension or Feature or other)
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 14]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+A.3. LDAP Syntax Registration Template
+
+ Subject: Request for LDAP Syntax Registration
+
+ Object Identifier:
+
+ Description:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.4. LDAP Descriptor Registration Template
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name):
+
+ Object Identifier:
+
+ Person & email address to contact for further information:
+
+ Usage: (One of administrative role, attribute type, matching rule,
+ name form, object class, URL extension, or other)
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.5. LDAP Attribute Description Option Registration Template
+
+ Subject: Request for LDAP Attribute Description Option Registration
+
+ Option Name:
+
+ Family of Options: (YES or NO)
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 15]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.6. LDAP Message Type Registration Template
+
+ Subject: Request for LDAP Message Type Registration
+
+ LDAP Message Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (Approved I-D)
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.7. LDAP Authentication Method Registration Template
+
+ Subject: Request for LDAP Authentication Method Registration
+
+ Authentication Method Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.8. LDAP Result Code Registration Template
+
+ Subject: Request for LDAP Result Code Registration
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 16]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ Result Code Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.8. LDAP Search Scope Registration Template
+
+ Subject: Request for LDAP Search Scope Registration
+
+ Search Scope Name:
+
+ Filter Scope String:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.9. LDAP Filter Choice Registration Template
+
+ Subject: Request for LDAP Filter Choice Registration
+
+ Filter Choice Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 17]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+A.10. LDAP ModifyRequest Operation Registration Template
+
+ Subject: Request for LDAP ModifyRequest Operation Registration
+
+ ModifyRequest Operation Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+Appendix B. Changes since RFC 3383
+
+ This informative appendix provides a summary of changes made since RFC
+ 3383.
+
+ - Object Identifier Descriptors practices were updated to require
+ all descriptors defined in RFCs to be registered and
+ recommending all other descriptors (excepting those in
+ private-use name space) be registered. Additionally, all
+ requests for multiple registrations of the same descriptor are
+ now subject to Expert Review.
+
+ - Protocol Mechanisms practices were updated to include values of
+ the 'supportedFeatures' attribute type.
+
+ - LDAP Syntax, Search Scope, Filter Choice, ModifyRequest
+ operation, and authzId prefixes registries were added.
+ [[Initial values provided in Appendix C. This Appendix is to be
+ removed by the RFC Editor before publication as an RFC.]]
+
+ - References to RFCs comprising the LDAP technical specifications
+ have been updated to latest revisions.
+
+ - References to ISO 10646 have been replaced with [Unicode].
+
+ - The "Assigned Values" appendix providing initial registry values
+ was removed.
+
+ - Numerous editorial changes were made.
+
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 18]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+Appendix C. Initial Values for new registries
+
+ This appendix provides initial values for new registries.
+
+
+C.1. LDAP Syntaxes
+
+ Object Identifier Syntax Owner Reference
+ ----------------------------- -------------------------- ----- ---
+ 1.3.6.1.4.1.1466.115.121.1.3 Attribute Type Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.6 Bit String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.7 Boolean IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.11 Country String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.12 DN IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.14 Delivery Method IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.15 Directory String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.16 DIT Content Rule Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.17 DIT Structure Rule Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.21 Enhanced Guide IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.22 Facsimile Telephone Number IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.23 Fax IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.24 Generalized Time IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.25 Guide IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.26 IA5 String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.27 Integer IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.28 JPEG IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.30 Matching Rule Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.31 Matching Rule Use Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.34 Name And Optional UID IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.35 Name Form Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.36 Numeric String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.37 Object Class Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.38 OID IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.39 Other Mailbox IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.40 Octet String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.41 Postal Address IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.44 Printable String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.50 Telephone Number IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.51 Teletex Terminal Identifier IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.52 Telex Number IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.53 UTC Time IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.54 LDAP Syntax Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.58 Substring Assertion IESG [Syntaxes]
+
+
+C.2. LDAP Search Scopes
+
+ Name URLString Value Owner Reference
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 19]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ ---------------- --------- ----- ----- -------------------
+ baseObject base 0 IESG [Protocol][LDAPURL]
+ singleLevel one 1 IESG [Protocol][LDAPURL]
+ wholeSubtree sub 2 IESG [Protocol][LDAPURL]
+
+
+C.3. LDAP Filter Choices
+
+ Name Value Owner Reference
+ ---------------- ----- ----- ---------
+ and 0 IESG [Protocol]
+ or 1 IESG [Protocol]
+ not 2 IESG [Protocol]
+ equalityMatch 3 IESG [Protocol]
+ substrings 4 IESG [Protocol]
+ greaterOrEqual 5 IESG [Protocol]
+ lessOrEqual 6 IESG [Protocol]
+ present 7 IESG [Protocol]
+ approxMatch 8 IESG [Protocol]
+ extensibleMatch 9 IESG [Protocol]
+
+
+C.4. LDAP ModifyRequest Operations
+
+ Name Value Owner Reference
+ ---------------- ----- ----- ---------
+ add 0 IESG [Protocol]
+ delete 1 IESG [Protocol]
+ replace 2 IESG [Protocol]
+
+
+C.5. LDAP authzId prefixes
+
+ Name Prefix Owner Reference
+ ---------------- ------ ----- ---------
+ dnAuthzId dn: IESG [AuthMeth]
+ uAuthzId u: IESG [AuthMeth]
+
+
+Full Copyright
+
+ 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
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 20]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ "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 at ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 21]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-dn-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-dn-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-dn-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,843 @@
+
+
+
+
+
+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 at openldap.org>. Please send editorial comments directly
+ to the document editor <Kurt at 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 at 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 at 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]
+
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-filter-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-filter-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-filter-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,724 @@
+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 at openldap.org>. Please send editorial comments directly
+ to the editor <mcs at 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: String Repres. of Search Filters 16 November 2004
+
+
+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.
+
+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
+
+ The Lightweight Directory Access Protocol (LDAP) [Roadmap] 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.
+
+ 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.
+
+
+
+
+
+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.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+2. LDAP Search Filter Definition
+
+ An LDAP search filter is defined in Section 4.5.1 of [Protocol] as
+ follows:
+
+ Filter ::= CHOICE {
+ and [0] SET SIZE (1..MAX) OF filter Filter,
+ or [1] SET SIZE (1..MAX) OF filter Filter,
+ not [2] Filter,
+ equalityMatch [3] AttributeValueAssertion,
+ substrings [4] SubstringFilter,
+ greaterOrEqual [5] AttributeValueAssertion,
+ lessOrEqual [6] AttributeValueAssertion,
+ present [7] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] MatchingRuleAssertion }
+
+ SubstringFilter ::= SEQUENCE {
+ type AttributeDescription,
+ -- initial and final can occur at most once
+ substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+ initial [0] AssertionValue,
+ any [1] AssertionValue,
+ final [2] AssertionValue } }
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ assertionValue AssertionValue }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE }
+
+ AttributeDescription ::= LDAPString
+ -- Constrained to <attributedescription>
+ -- [Models]
+
+ 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
+
+ LDAPString ::= OCTET STRING -- UTF-8 encoded,
+ -- [Unicode] characters
+
+ The AttributeDescription, as defined in [Protocol], 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
+ transmission over a network using the Basic Encoding Rules (BER)
+ defined in [X.690], with simplifications described in [Protocol].
+
+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
+ otherwise noted. The filter format uses a prefix notation.
+
+ filter = LPAREN filtercomp RPAREN
+ filtercomp = and / or / not / item
+ and = AMPERSAND filterlist
+ or = VERTBAR filterlist
+ not = EXCLAMATION filter
+ filterlist = 1*filter
+ item = simple / present / substring / extensible
+ simple = attr filtertype assertionvalue
+ filtertype = equal / approx / greaterorequal / lessorequal
+ equal = EQUALS
+ approx = TILDE EQUALS
+ greaterorequal = RANGLE EQUALS
+ lessorequal = LANGLE EQUALS
+ extensible = ( attr [dnattrs]
+ [matchingrule] COLON EQUALS assertionvalue )
+ / ( [dnattrs]
+ matchingrule COLON EQUALS assertionvalue )
+ present = attr EQUALS ASTERISK
+ substring = attr EQUALS [initial] any [final]
+ initial = assertionvalue
+ any = ASTERISK *(assertionvalue ASTERISK)
+ final = assertionvalue
+ attr = attributedescription
+ ; The attributedescription rule is defined in
+ ; Section 2.5 of [Models].
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 4]
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+ dnattrs = COLON "dn"
+ matchingrule = COLON oid
+ assertionvalue = valueencoding
+ ; The <valueencoding> rule is used to encode an <AssertionValue>
+ ; from Section 4.1.6 of [Protocol].
+ valueencoding = 0*(normal / escaped)
+ normal = UTF1SUBSET / UTFMB
+ escaped = ESC HEX HEX
+ UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F
+ ; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
+ ; RPAREN, ASTERISK, and ESC.
+ EXCLAMATION = %x21 ; exclamation mark ("!")
+ AMPERSAND = %x26 ; ampersand (or AND symbol) ("&")
+ ASTERISK = %x2A ; asterisk ("*")
+ COLON = %x3A ; colon (":")
+ VERTBAR = %x7C ; vertical bar (or pipe) ("|")
+ TILDE = %x7E ; tilde ("~")
+
+
+ Note that although both the <substring> and <present> productions in
+ the grammar above can produce the "attr=*" construct, this construct
+ is used only to denote a presence filter.
+
+ The <valueencoding> rule ensures that the entire filter string is a
+ valid UTF-8 string and provides that the octets that represent the
+ ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII
+ 0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a
+ backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits
+ representing the value of the encoded octet.
+
+ This simple escaping mechanism eliminates filter-parsing ambiguities
+ and allows any filter that can be represented in LDAP to be
+ represented as a NUL-terminated string. Other octets that are part of
+ the <normal> set may be escaped using this mechanism, for example,
+ non-printing ASCII characters.
+
+ For AssertionValues that contain UTF-8 character data, each octet of
+ the character to be escaped is replaced by a backslash and two hex
+ digits, which form a single octet in the code of the character. For
+ example, the filter checking whether the "cn" attribute contained a
+ value with the character "*" anywhere in it would be represented as
+ "(cn=*\2a*)".
+
+ As indicated by the <valueencoding> rule, implementations MUST escape
+ all octets greater than 0x7F that are not part of a valid UTF-8
+ encoding sequence when they generate a string representation of a
+ search filter. Implementations SHOULD accept as input strings that
+ are not valid UTF-8 strings. This is necessary because RFC 2254 did
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 5]
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+ not clearly define the term "string representation" (and in
+ particular did not mention that the string representation of an LDAP
+ search filter is a string of UTF-8 encoded Unicode characters).
+
+4. Examples
+
+ This section gives a few examples of search filters written using
+ this notation.
+
+ (cn=Babs Jensen)
+ (!(cn=Tim Howes))
+ (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
+ (o=univ*of*mich*)
+ (seeAlso=)
+
+ The following examples illustrate the use of extensible matching.
+
+ (cn:caseExactMatch:=Fred Flintstone)
+ (cn:=Betty Rubble)
+ (sn:dn:2.4.6.8.10:=Barney Rubble)
+ (o:dn:=Ace Industry)
+ (:1.2.3:=Wilma Flintstone)
+ (:DN:2.4.6.8.10:=Dino)
+
+ The first example shows use of the matching rule "caseExactMatch."
+
+ The second example demonstrates use of a MatchingRuleAssertion form
+ without a matchingRule.
+
+ 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
+ entry's distinguished name should be considered part of the entry
+ when evaluating the match (indicated by the use of ":dn").
+
+ The fourth example denotes an equality match, except that DN
+ components should be considered part of the entry when doing the
+ match.
+
+ The fifth example is a filter that should be applied to any attribute
+ supporting the matching rule given (since the <attr> has been
+ omitted).
+
+ The sixth and final example is also a filter that should be applied
+ to any attribute supporting the matching rule given. Attributes
+ supporting the matching rule contained in the DN should also be
+ considered.
+
+
+
+
+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)
+ (cn=*\2A*)
+ (filename=C:\5cMyFile)
+ (bin=\00\00\00\04)
+ (sn=Lu\c4\8di\c4\87)
+ (1.3.6.1.4.1.1466.0=\04\02\48\69)
+
+ The first example shows the use of the escaping mechanism to
+ represent parenthesis characters. The second shows how to represent a
+ "*" in an assertion value, preventing it from being interpreted as a
+ substring indicator. The third illustrates the escaping of the
+ backslash character.
+
+ The fourth example shows a filter searching for the four octet value
+ 00 00 00 04 (hex), illustrating the use of the escaping mechanism to
+ represent arbitrary data, including NUL characters.
+
+ The fifth example illustrates the use of the escaping mechanism to
+ represent various non-ASCII UTF-8 characters. Specifically, there are
+ 5 characters in the <assertionvalue> portion of this example: LATIN
+ CAPITAL LETTER L (U+004C), LATIN SMALL LETTER U (U+0075), LATIN SMALL
+ LETTER C WITH CARON (U+010D), LATIN SMALL LETTER I (U+0069), and
+ LATIN SMALL LETTER C WITH ACUTE (U+0107).
+
+ The sixth and final example demonstrates assertion of a BER encoded
+ value.
+
+5. Security Considerations
+
+ This memo describes a string representation of LDAP search filters.
+ While the representation itself has no known security implications,
+ LDAP search filters do. They are interpreted by LDAP servers to
+ select entries from which data is retrieved. LDAP servers should
+ take care to protect the data they maintain from unauthorized access.
+
+ Please refer to the Security Considerations sections of [Protocol]
+ and [AuthMeth] for more information.
+
+6. IANA Considerations
+
+ This document has no actions for IANA.
+
+7. Normative References
+
+[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
+ Connection Level Security Mechanisms",
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 7]
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+ draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
+
+[Models] Zeilenga, K. (editor), "LDAP: Directory Information Models",
+ draft-ietf-ldapbis-models-xx.txt, a work in progress.
+
+[Protocol] draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+[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
+
+ This document replaces RFC 2254 by Tim Howes. RFC 2254 was a product
+ of the IETF ASID Working Group.
+
+ Changes included in this revised specification are based upon
+ discussions among the authors, discussions within the LDAP (v3)
+ Revision Working Group (ldapbis), and discussions within other IETF
+ Working Groups. The contributions of individuals in these working
+ groups is gratefully acknowledged.
+
+
+
+Smith & 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 at pearlcrescent.com
+
+
+ Tim Howes
+ Opsware, Inc.
+ 599 N. Mathilda Ave.
+ Sunnyvale, CA 94085
+ USA
+ +1 408 744-7509
+ howes at opsware.com
+
+11. Appendix A: Changes Since RFC 2254
+
+11.1. Technical Changes
+
+ Replaced [ISO 10646] reference with [Unicode].
+
+ The following technical changes were made to the contents of the
+ "String Search Filter Definition" section:
+
+ Added statement that the string representation is a string of UTF-8
+ encoded Unicode characters.
+
+ Revised all of the ABNF to use common productions from [Models].
+
+ 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].
+
+ 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]
+ 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"
+ 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
+
+ Changed document title to include "LDAP:" prefix.
+
+ IESG Note: removed note about lack of satisfactory mandatory
+ authentication mechanisms.
+
+ Header and "Authors' Addresses" sections: added Mark Smith as the
+ document editor and updated affiliation and contact information.
+
+ "Table of Contents", "IANA Considerations", and "Intellectual
+ Property Rights" sections: added.
+
+ Copyright: updated per latest IETF guidelines.
+
+ "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.
+
+ "LDAP Search Filter Definition" section: made corrections to the LDAP
+ search filter ABNF so it matches that used in [Protocol].
+
+ 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
+ characters). Added a note that each octet of a character to be
+ escaped is replaced by a backslash and two hex digits, which
+ represent a single octet.
+
+ "Examples" section: added four additional examples: (seeAlso=),
+ (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and
+ (1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a
+ value" with "an assertion value". Corrected the description of this
+ example: (sn:dn:2.4.6.8.10:=Barney Rubble). Replaced the numeric OID
+ in the first extensible match example with "caseExactMatch" to
+ demonstrate use of the descriptive form. Used "DN" (uppercase) in
+
+
+
+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].
+
+ "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.
+
+ "Informative References" section: (new section) moved [X.690] to this
+ section. Added a reference to [LDAPURL].
+
+ "Acknowledgments" 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
+
+ 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."
+
+
+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
+
+
+
+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.
+
+ 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 at 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
+ "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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 13]
\ No newline at end of file
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-models-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-models-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-models-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,2857 @@
+
+
+
+
+INTERNET-DRAFT Editor: Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 21 February 2005
+Obsoletes: RFC 2251, RFC 2252, RFC 2256, RFC 3674
+
+
+
+ LDAP: Directory Information Models
+ <draft-ietf-ldapbis-models-14.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 at openldap.org>. Please send editorial
+ comments directly to the editor <Kurt at 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 Models [Page 1]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 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
+ describes the X.500 Directory Information Models, as used in LDAP.
+
+Table of Contents
+
+ Status of this Memo 1
+ Abstract 2
+ Table of Contents
+ 1. Introduction 3
+ 1.1. Relationship to Other LDAP Specifications
+ 1.2. Relationship to X.501 4
+ 1.3. Conventions
+ 1.4. Common ABNF Productions
+ 2. Model of Directory User Information 6
+ 2.1. The Directory Information Tree 7
+ 2.2. Structure of an Entry
+ 2.3. Naming of Entries 8
+ 2.4. Object Classes 9
+ 2.5. Attribute Descriptions 12
+ 2.6. Alias Entries 16
+ 3. Directory Administrative and Operational Information 17
+ 3.1. Subtrees
+ 3.2. Subentries 18
+ 3.3. The 'objectClass' attribute
+ 3.4. Operational attributes 19
+ 4. Directory Schema 22
+ 4.1. Schema Definitions 23
+ 4.2. Subschema Subentries 32
+ 4.3. 'extensibleObject' 35
+ 4.4. Subschema Discovery 36
+ 5. DSA (Server) Informational Model
+ 5.1. Server-specific Data Requirements 37
+ 6. Other Considerations 40
+ 6.1. Preservation of User Information 41
+ 6.2. Short Names
+ 6.3. Cache and Shadowing
+ 7. Implementation Guidelines 42
+ 7.1. Server Guidelines
+ 7.2. Client Guidelines
+ 8. Security Considerations 43
+ 9. IANA Considerations
+ 10. Acknowledgments 44
+ 11. Editor's Address
+ 12. References
+
+
+
+Zeilenga LDAP Models [Page 2]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ 12.1. Normative References 45
+ 12.2. Informative References
+ Appendix A. Changes
+ Intellectual Property Rights 51
+ Full Copyright
+
+
+1. Introduction
+
+ This document discusses the X.500 Directory Information Models
+ [X.501], as used by the Lightweight Directory Access Protocol (LDAP)
+ [Roadmap].
+
+ The Directory is "a collection of open systems cooperating to provide
+ directory services" [X.500]. The information held in the Directory is
+ collectively known as the Directory Information Base (DIB). A
+ Directory user, which may be a human or other entity, accesses the
+ Directory through a client (or Directory User Agent (DUA)). The
+ client, on behalf of the directory user, interacts with one or more
+ servers (or Directory System Agents (DSA)). A server holds a fragment
+ of the DIB.
+
+ The DIB contains two classes of information:
+
+ 1) user information (e.g., information provided and administrated
+ by users). Section 2 describes the Model of User Information.
+
+ 2) administrative and operational information (e.g., information
+ used to administer and/or operate the directory). Section 3
+ describes the model of Directory Administrative and Operational
+ Information.
+
+ These two models, referred to as the generic Directory Information
+ Models, describe how information is represented in the Directory.
+ These generic models provide a framework for other information models.
+ Section 4 discusses the subschema information model and subschema
+ discovery. Section 5 discusses the DSA (Server) Informational Model.
+
+ Other X.500 information models, such as access control distribution
+ knowledge, and replication knowledge information models, may be
+ adapted for use in LDAP. Specification of how these models apply to
+ LDAP is left to future documents.
+
+
+1.1. Relationship to Other LDAP Specifications
+
+ This document is a integral part of the LDAP technical specification
+ [Roadmap] which obsoletes the previously defined LDAP technical
+
+
+
+Zeilenga LDAP Models [Page 3]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ specification, RFC 3377, in its entirety.
+
+ This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as
+ portions of sections 4 and 6. Appendix A.1 summarizes changes to
+ these sections. The remainder of RFC 2251 is obsoleted by the
+ [Protocol], [AuthMeth], and [Roadmap] documents.
+
+ This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2
+ summarizes changes to these sections. The remainder of RFC 2252 is
+ obsoleted by [Syntaxes].
+
+ This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2.
+ Appendix A.3 summarizes changes to these sections. The remainder of
+ RFC 2256 is obsoleted by [Schema] and [Syntaxes].
+
+ This document obsoletes RFC 3674 in its entirety. Appendix A.4
+ summarizes changes since RFC 3674.
+
+
+1.2. Relationship to X.501
+
+ This document includes material, with and without adaptation, from
+ [X.501] as necessary to describe this protocol. These adaptations
+ (and any other differences herein) apply to this protocol, and only
+ this protocol.
+
+
+1.3. 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].
+
+ Schema definitions are provided using LDAP description formats (as
+ defined in Section 4.1). Definitions provided here are formatted
+ (line wrapped) for readability. Matching rules and LDAP syntaxes
+ referenced in these definitions are specified in [Syntaxes].
+
+
+1.4. Common ABNF Productions
+
+ A number of syntaxes in this document are described using Augmented
+ Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a
+ number of syntaxes defined in other documents) rely on the following
+ common productions:
+
+ keystring = leadkeychar *keychar
+ leadkeychar = ALPHA
+
+
+
+Zeilenga LDAP Models [Page 4]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ keychar = ALPHA / DIGIT / HYPHEN
+ number = DIGIT / ( LDIGIT 1*DIGIT )
+
+ ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
+ DIGIT = %x30 / LDIGIT ; "0"-"9"
+ LDIGIT = %x31-39 ; "1"-"9"
+ HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
+
+ SP = 1*SPACE ; one or more " "
+ WSP = 0*SPACE ; zero or more " "
+
+ NULL = %x00 ; null (0)
+ SPACE = %x20 ; space (" ")
+ DQUOTE = %x22 ; quote (""")
+ SHARP = %x23 ; octothorpe (or sharp sign) ("#")
+ DOLLAR = %x24 ; dollar sign ("$")
+ SQUOTE = %x27 ; single quote ("'")
+ LPAREN = %x28 ; left paren ("(")
+ RPAREN = %x29 ; right paren (")")
+ PLUS = %x2B ; plus sign ("+")
+ COMMA = %x2C ; comma (",")
+ HYPHEN = %x2D ; hyphen ("-")
+ DOT = %x2E ; period (".")
+ SEMI = %x3B ; semicolon (";")
+ LANGLE = %x3C ; left angle bracket ("<")
+ EQUALS = %x3D ; equals sign ("=")
+ RANGLE = %x3E ; right angle bracket (">")
+ ESC = %x5C ; backslash ("\")
+ USCORE = %x5F ; underscore ("_")
+ LCURLY = %x7B ; left curly brace "{"
+ RCURLY = %x7D ; right curly brace "}"
+
+ ; Any UTF-8 [UTF-8] encoded Unicode [Unicode] character
+ UTF8 = UTF1 / UTFMB
+ UTFMB = UTF2 / UTF3 / UTF4
+ UTF0 = %x80-BF
+ UTF1 = %x00-7F
+ UTF2 = %xC2-DF UTF0
+ UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
+ %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
+ UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
+ %xF4 %x80-8F 2(UTF0)
+
+ OCTET = %x00-FF ; Any octet (8-bit data unit)
+
+ Object identifiers (OIDs) [X.680] are represented in LDAP using a
+ dot-decimal format conforming to the ABNF:
+
+
+
+
+Zeilenga LDAP Models [Page 5]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ numericoid = number 1*( DOT number )
+
+ Short names, also known as descriptors, are used as more readable
+ aliases for object identifiers. Short names are case insensitive and
+ conform to the ABNF:
+
+ descr = keystring
+
+ Where either an object identifier or a short name may be specified,
+ the following production is used:
+
+ oid = descr / numericoid
+
+ While the <descr> form is generally preferred when the usage is
+ restricted to short names referring to object identifiers which
+ identify like kinds of objects (e.g., attribute type descriptions,
+ matching rule descriptions, object class descriptions), the
+ <numericoid> form should be used when the object identifiers may
+ identify multiple kinds of objects or when an unambiguous short name
+ (descriptor) is not available.
+
+ Implementations SHOULD treat short names (descriptors) used in an
+ ambiguous manner (as discussed above) as unrecognized.
+
+ Short Names (descriptors) are discussed further in Section 6.2.
+
+
+2. Model of Directory User Information
+
+ As [X.501] states:
+
+ The purpose of the Directory is to hold, and provide access to,
+ information about objects of interest (objects) in some 'world'.
+ An object can be anything which is identifiable (can be named).
+
+ An object class is an identified family of objects, or conceivable
+ objects, which share certain characteristics. Every object belongs
+ to at least one class. An object class may be a subclass of other
+ object classes, in which case the members of the former class, the
+ subclass, are also considered to be members of the latter classes,
+ the superclasses. There may be subclasses of subclasses, etc., to
+ an arbitrary depth.
+
+ A directory entry, a named collection of information, is the basic
+ unit of information held in the Directory. There are multiple kinds
+ of directory entries.
+
+ An object entry represents a particular object. An alias entry
+
+
+
+Zeilenga LDAP Models [Page 6]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ provides alternative naming. A subentry holds administrative and/or
+ operational information.
+
+ The set of entries representing the DIB are organized hierarchically
+ in a tree structure known as the Directory Information Tree (DIT).
+
+ Section 2.1 describes the Directory Information Tree
+ Section 2.2 discusses the structure of entries.
+ Section 2.3 discusses naming of entries.
+ Section 2.4 discusses object classes.
+ Section 2.5 discusses attribute descriptions.
+ Section 2.6 discusses alias entries.
+
+
+2.1. The Directory Information Tree
+
+ As noted above, the DIB is composed of a set of entries organized
+ hierarchically in a tree structure known as the Directory Information
+ Tree (DIT). Specifically, a tree where vertices are the entries.
+
+ The arcs between vertices define relations between entries. If an arc
+ exists from X to Y, then the entry at X is the immediate superior of Y
+ and Y is the immediate subordinate of X. An entry's superiors are the
+ entry's immediate superior and its superiors. An entry's subordinates
+ are all of its immediate subordinates and their subordinates.
+
+ Similarly, the superior/subordinate relationship between object
+ entries can be used to derive a relation between the objects they
+ represent. DIT structure rules can be used to govern relationships
+ between objects.
+
+ Note: An entry's immediate superior is also known as the entry's
+ parent and an entry's immediate subordinate is also known as the
+ entry's child. Entries which have the same parent are known as
+ siblings.
+
+
+2.2. Structure of an Entry
+
+ An entry consists of a set of attributes which hold information about
+ the object which the entry represents. Some attributes represent user
+ information and are called user attributes. Other attributes
+ represent operational and/or administrative information and are called
+ operational attributes.
+
+ An attribute is an attribute description (a type and zero or more
+ options) with one or more associated values. An attribute is often
+ referred to by its attribute description. For example, the
+
+
+
+Zeilenga LDAP Models [Page 7]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ 'givenName' attribute is the attribute which consists of the attribute
+ description 'givenName' (the 'givenName' attribute type [Schema] and
+ zero options) and one or more associated values.
+
+ The attribute type governs whether the attribute can have multiple
+ values, the syntax and matching rules used to construct and compare
+ values of that attribute, and other functions. Options indicate
+ subtypes and other functions.
+
+ Attribute values conform to the defined syntax of the attribute type.
+
+ No two values of an attribute may be equivalent. Two values are
+ considered equivalent if and only if they would match according to the
+ equality matching rule of the attribute type or, if the attribute type
+ is defined with no equality matching rule, two values are equivalent
+ if and only if they are identical. (See 2.5.1 for other
+ restrictions.)
+
+ For example, a 'givenName' attribute can have more than one value,
+ they must be Directory Strings, and they are case insensitive. A
+ 'givenName' attribute cannot hold both "John" and "JOHN" as these are
+ equivalent values per the equality matching rule of the attribute
+ type.
+
+ Additionally, no attribute is to have a value which is not equivalent
+ to itself. For example, the 'givenName' attribute cannot have as a
+ value a directory string which includes the REPLACEMENT CHARACTER
+ (U+FFFD) code point as matching involving that directory string is
+ Undefined per this attribute's equality matching rule.
+
+ When an attribute is used for naming of the entry, one and only one
+ value of the attribute is used in forming the Relative Distinguished
+ Name. This value is known as a distinguished value.
+
+
+2.3. Naming of Entries
+
+2.3.1. Relative Distinguished Names
+
+ Each entry is named relative to its immediate superior. This relative
+ name, known as its Relative Distinguished Name (RDN) [X.501], is
+ composed of an unordered set of one or more attribute value assertions
+ (AVA) consisting of an attribute description with zero options and an
+ attribute value. These AVAs are chosen to match attribute values
+ (each a distinguished value) of the entry.
+
+ An entry's relative distinguished name must be unique among all
+ immediate subordinates of the entry's immediate superior (i.e., all
+
+
+
+Zeilenga LDAP Models [Page 8]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ siblings).
+
+ The following are examples of string representations of RDNs [LDAPDN]:
+
+ UID=12345
+ OU=Engineering
+ CN=Kurt Zeilenga+L=Redwood Shores
+
+ The last is an example of a multi-valued RDN. That is, an RDN
+ composed of multiple AVAs.
+
+
+2.3.2. Distinguished Names
+
+ An entry's fully qualified name, known as its Distinguished Name (DN)
+ [X.501], is the concatenation of its RDN and its immediate superior's
+ DN. A Distinguished Name unambiguously refers to an entry in the
+ tree. The following are examples of string representations of DNs
+ [LDAPDN]:
+
+ UID=nobody at example.com,DC=example,DC=com
+ CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
+
+
+2.3.3. Alias Names
+
+ An alias, or alias name, is "an name for an object, provided by the
+ use of alias entries" [X.501]. Alias entries are described in Section
+ 2.6.
+
+
+2.4. Object Classes
+
+ An object class is "an identified family of objects (or conceivable
+ objects) which share certain characteristics" [X.501].
+
+ As defined in [X.501]:
+
+ Object classes are used in the Directory for a number of purposes:
+
+ - describing and categorising objects and the entries that
+ correspond to these objects;
+
+ - where appropriate, controlling the operation of the Directory;
+
+ - regulating, in conjunction with DIT structure rule
+ specifications, the position of entries in the DIT;
+
+
+
+
+Zeilenga LDAP Models [Page 9]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ - regulating, in conjunction with DIT content rule
+ specifications, the attributes that are contained in entries;
+
+ - identifying classes of entry that are to be associated with a
+ particular policy by the appropriate administrative authority.
+
+ An object class (a subclass) may be derived from an object class
+ (its direct superclass) which is itself derived from an even more
+ generic object class. For structural object classes, this process
+ stops at the most generic object class, 'top' (defined in Section
+ 2.4.1). An ordered set of superclasses up to the most superior
+ object class of an object class is its superclass chain.
+
+ An object class may be derived from two or more direct
+ superclasses (superclasses not part of the same superclass chain).
+ This feature of subclassing is termed multiple inheritance.
+
+ Each object class identifies the set of attributes required to be
+ present in entries belonging to the class and the set of attributes
+ allowed to be present in entries belonging to the class. As an entry
+ of a class must meet the requirements of each class it belongs to, it
+ can be said that an object class inherits the sets of allowed and
+ required attributes from its superclasses. A subclass can identify an
+ attribute allowed by its superclass as being required. If an
+ attribute is a member of both sets, it is required to be present.
+
+ Each object class is defined to be one of three kinds of object
+ classes: Abstract, Structural, or Auxiliary.
+
+ Each object class is identified by an object identifier (OID) and,
+ optionally, one or more short names (descriptors).
+
+
+2.4.1. Abstract Object Classes
+
+ An abstract object class, as the name implies, provides a base of
+ characteristics from which other object classes can be defined to
+ inherit from. An entry cannot belong to an abstract object class
+ unless it belongs to a structural or auxiliary class which inherits
+ from that abstract class.
+
+ Abstract object classes can not derive from structural nor auxiliary
+ object classes.
+
+ All structural object classes derive (directly or indirectly) from the
+ 'top' abstract object class. Auxiliary object classes do not
+ necessarily derive from 'top'.
+
+
+
+
+Zeilenga LDAP Models [Page 10]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ The following is the object class definition (see Section 4.1.1) for
+ the 'top' object class:
+
+ ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
+
+ All entries belong to the 'top' abstract object class.
+
+
+2.4.2. Structural Object Classes
+
+ As stated in [X.501]:
+
+ An object class defined for use in the structural specification of
+ the DIT is termed a structural object class. Structural object
+ classes are used in the definition of the structure of the names
+ of the objects for compliant entries.
+
+ An object or alias entry is characterised by precisely one
+ structural object class superclass chain which has a single
+ structural object class as the most subordinate object class.
+ This structural object class is referred to as the structural
+ object class of the entry.
+
+ Structural object classes are related to associated entries:
+
+ - an entry conforming to a structural object class shall
+ represent the real-world object constrained by the object
+ class;
+
+ - DIT structure rules only refer to structural object classes;
+ the structural object class of an entry is used to specify the
+ position of the entry in the DIT;
+
+ - the structural object class of an entry is used, along with an
+ associated DIT content rule, to control the content of an
+ entry.
+
+ The structural object class of an entry shall not be changed.
+
+ Each structural object class is a (direct or indirect) subclass of the
+ 'top' abstract object class.
+
+ Structural object classes cannot subclass auxiliary object classes.
+
+ Each entry is said to belong to its structural object class as well as
+ all classes in its structural object class's superclass chain.
+
+
+
+
+
+Zeilenga LDAP Models [Page 11]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+2.4.3. Auxiliary Object Classes
+
+ Auxiliary object classes are used to augment the characteristics of
+ entries. They are commonly used to augment the sets of attributes
+ required and allowed to be present in an entry. They can be used to
+ describe entries or classes of entries.
+
+ Auxiliary object classes cannot subclass structural object classes.
+
+ An entry can belong to any subset of the set of auxiliary object
+ classes allowed by the DIT content rule associated with the structural
+ object class of the entry. If no DIT content rule is associated with
+ the structural object class of the entry, the entry cannot belong to
+ any auxiliary object class.
+
+ The set of auxiliary object classes which an entry belongs to can
+ change over time.
+
+
+2.5. Attribute Descriptions
+
+ An attribute description is composed of an attribute type (see Section
+ 2.5.1) and a set of zero or more attribute options (see Section
+ 2.5.2).
+
+ An attribute description is represented by the ABNF:
+
+ attributedescription = attributetype options
+ attributetype = oid
+ options = *( SEMI option )
+ option = 1*keychar
+
+ where <attributetype> identifies the attribute type and each <option>
+ identifies an attribute option. Both <attributetype> and <option>
+ productions are case insensitive. The order in which <option>s appear
+ is irrelevant. That is, any two <attributedescription>s which consist
+ of the same <attributetype> and same set of <option>s are equivalent.
+
+ Examples of valid attribute descriptions:
+
+ 2.5.4.0
+ cn;lang-de;lang-en
+ owner
+
+ An attribute description with an unrecognized attribute type is to be
+ treated as unrecognized. Servers SHALL treat an attribute description
+ with an unrecognized attribute option as unrecognized. Clients MAY
+ treat an unrecognized attribute option as a tagging option (see
+
+
+
+Zeilenga LDAP Models [Page 12]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ Section 2.5.2.1).
+
+ All attributes of an entry must have distinct attribute descriptions.
+
+
+2.5.1. Attribute Types
+
+ An attribute type governs whether the attribute can have multiple
+ values, the syntax and matching rules used to construct and compare
+ values of that attribute, and other functions.
+
+ If no equality matching is specified for the attribute type:
+ - the attribute (of the type) cannot be used for naming;
+ - when adding the attribute (or replacing all values), no two values
+ may be equivalent (see 2.2);
+ - individual values of a multi-valued attribute are not to be
+ independently added or deleted;
+ - attribute value assertions (such as matching in search filters and
+ comparisons) using values of such a type cannot be performed.
+
+ Otherwise, the specified equality matching rule is to be used for the
+ purposes of evaluating attribute value assertions concerning the
+ attribute type. The specified equality rule is to be transitive and
+ commutative.
+
+ The attribute type indicates whether the attribute is a user attribute
+ or an operational attribute. If operational, the attribute type
+ indicates the operational usage and whether the attribute is
+ modifiable by users or not. Operational attributes are discussed in
+ Section 3.4.
+
+ An attribute type (a subtype) may derive from a more generic attribute
+ type (a direct supertype). The following restrictions apply to
+ subtyping:
+ - a subtype must have the same usage as its direct supertype,
+ - a subtype's syntax must be the same, or a refinement of, its
+ supertype's syntax, and
+ - a subtype must be collective [RFC3671] if its supertype is
+ collective.
+
+ An attribute description consisting of a subtype and no options is
+ said to be the direct description subtype of the attribute description
+ consisting of the subtype's direct supertype and no options.
+
+ Each attribute type is identified by an object identifier (OID) and,
+ optionally, one or more short names (descriptors).
+
+
+
+
+
+Zeilenga LDAP Models [Page 13]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+2.5.2. Attribute Options
+
+ There are multiple kinds of attribute description options. The LDAP
+ technical specification details one kind: tagging options.
+
+ Not all options can be associated with attributes held in the
+ directory. Tagging options can be.
+
+ Not all options can be used in conjunction with all attribute types.
+ In such cases, the attribute description is to be treated as
+ unrecognized.
+
+ An attribute description that contains mutually exclusive options
+ shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where
+ "x-foo" and "x-bar" are mutually exclusive, is to be treated as
+ unrecognized.
+
+ Other kinds of options may be specified in future documents. These
+ documents must detail how new kinds of options they define relate to
+ tagging options. In particular, these documents must detail whether
+ or not new kinds of options can be associated with attributes held in
+ the directory, how new kinds of options affect transfer of attribute
+ values, and how new kinds of options are treated in attribute
+ description hierarchies.
+
+ Options are represented as short case insensitive textual strings
+ conforming to the <option> production defined in Section 2.5 of this
+ document.
+
+ Procedures for registering options are detailed in BCP 64 [BCP64bis].
+
+
+2.5.2.1. Tagging Options
+
+ Attributes held in the directory can have attribute descriptions with
+ any number of tagging options. Tagging options are never mutually
+ exclusive.
+
+ An attribute description with N tagging options is a direct
+ (description) subtype of all attribute descriptions of the same
+ attribute type and all but one of the N options. If the attribute
+ type has a supertype, then the attribute description is also a direct
+ (description) subtype of the attribute description of the supertype
+ and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct
+ (description) subtype of 'cn;lang-de', 'cn;lang-en', and
+ 'name;lang-de;lang-en' ('cn' is a subtype of 'name', both are defined
+ in [Schema]).
+
+
+
+
+Zeilenga LDAP Models [Page 14]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+2.5.3. Attribute Description Hierarchies
+
+ An attribute description can be the direct subtype of zero or more
+ other attribute descriptions as indicated by attribute type subtyping
+ (as described in Section 2.5.1) or attribute tagging option subtyping
+ (as described in Section 2.5.2.1). These subtyping relationships are
+ used to form hierarchies of attribute descriptions and attributes.
+
+ As adapted from [X.501]:
+
+ Attribute hierarchies allow access to the DIB with varying degrees
+ of granularity. This is achieved by allowing the value components
+ of attributes to be accessed by using either their specific
+ attribute description (a direct reference to the attribute) or by
+ a more generic attribute description (an indirect reference).
+
+ Semantically related attributes may be placed in a hierarchical
+ relationship, the more specialized being placed subordinate to the
+ more generalized. Searching for, or retrieving attributes and
+ their values is made easier by quoting the more generalized
+ attribute description; a filter item so specified is evaluated for
+ the more specialized descriptions as well as for the quoted
+ description.
+
+ Where subordinate specialized descriptions are selected to be
+ returned as part of a search result these descriptions shall be
+ returned if available. Where the more general descriptions are
+ selected to be returned as part of a search result both the
+ general and the specialized descriptions shall be returned, if
+ available. An attribute value shall always be returned as a value
+ of its own attribute description.
+
+ All of the attribute descriptions in an attribute hierarchy are
+ treated as distinct and unrelated descriptions for user
+ modification of entry content.
+
+ An attribute value stored in an object or alias entry is of
+ precisely one attribute description. The description is indicated
+ when the value is originally added to the entry.
+
+ For the purpose of subschema administration of the entry, a
+ specification that an attribute is required is fulfilled if the entry
+ contains a value of an attribute description belonging to an attribute
+ hierarchy where the attribute type of that description is the same as
+ the required attribute's type. That is, a "MUST name" specification
+ is fulfilled by 'name' or 'name;x-tag-option', but is not fulfilled by
+ 'CN' nor by 'CN;x-tag-option' (even though 'CN' is a subtype of
+ 'name'). Likewise, an entry may contain a value of an attribute
+
+
+
+Zeilenga LDAP Models [Page 15]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ description belonging to an attribute hierarchy where the attribute
+ type of that description is either explicitly included in the
+ definition of an object class to which the entry belongs or allowed by
+ the DIT content rule applicable to that entry. That is, 'name' and
+ 'name;x-tag-option' are allowed by "MAY name" (or by "MUST name"), but
+ 'CN' and 'CN;x-tag-option' are not allowed by "MAY name" (nor by "MUST
+ name").
+
+ For the purposes of other policy administration, unless stated
+ otherwise in the specification of the particular administrative model,
+ all of the attribute descriptions in an attribute hierarchy are
+ treated as distinct and unrelated descriptions.
+
+
+2.6. Alias Entries
+
+ As adapted from [X.501]:
+
+ An alias, or an alias name, for an object is an alternative name
+ for an object or object entry which is provided by the use of
+ alias entries.
+
+ Each alias entry contains, within the 'aliasedObjectName'
+ attribute (known as the 'aliasedEntryName' attribute in X.500]), a
+ name of some object. The distinguished name of the alias entry is
+ thus also a name for this object.
+
+ NOTE - The name within the 'aliasedObjectName' is said to be
+ pointed to by the alias. It does not have to be the
+ distinguished name of any entry.
+
+ The conversion of an alias name to an object name is termed
+ (alias) dereferencing and comprises the systematic replacement of
+ alias names, where found within a purported name, by the value of
+ the corresponding 'aliasedObjectName' attribute. The process may
+ require the examination of more than one alias entry.
+
+ Any particular entry in the DIT may have zero or more alias names.
+ It therefore follows that several alias entries may point to the
+ same entry. An alias entry may point to an entry that is not a
+ leaf entry and may point to another alias entry.
+
+ An alias entry shall have no subordinates, so that an alias entry
+ is always a leaf entry.
+
+ Every alias entry shall belong to the 'alias' object class.
+
+ An entry with the 'alias' object class must also belong to an object
+
+
+
+Zeilenga LDAP Models [Page 16]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ class (or classes), or be governed by a DIT content rule, which allows
+ suitable naming attributes to be present.
+
+ Example:
+ dn: cn=bar,dc=example,dc=com
+ objectClass: top
+ objectClass: alias
+ objectClass: extensibleObject
+ cn: bar
+ aliasedObjectName: cn=foo,dc=example,dc=com
+
+
+2.6.1. 'alias' object class
+
+ Alias entries belong to the 'alias' object class.
+
+ ( 2.5.6.1 NAME 'alias'
+ SUP top STRUCTURAL
+ MUST aliasedObjectName )
+
+
+2.6.2. 'aliasedObjectName' attribute type
+
+ The 'aliasedObjectName' attribute holds the name of the entry an alias
+ points to. The 'aliasedObjectName' attribute is known as the
+ 'aliasedEntryName' attribute in X.500.
+
+ ( 2.5.4.1 NAME 'aliasedObjectName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE )
+
+ The 'distinguishedNameMatch' matching rule and the DistinguishedName
+ (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
+
+
+3. Directory Administrative and Operational Information
+
+ This section discusses select aspects of the X.500 Directory
+ Administrative and Operational Information model [X.501]. LDAP
+ implementations MAY support other aspects of this model.
+
+
+3.1. Subtrees
+
+ As defined in [X.501]:
+
+ A subtree is a collection of object and alias entries situated at
+
+
+
+Zeilenga LDAP Models [Page 17]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ the vertices of a tree. Subtrees do not contain subentries. The
+ prefix sub, in subtree, emphasizes that the base (or root) vertex
+ of this tree is usually subordinate to the root of the DIT.
+
+ A subtree begins at some vertex and extends to some identifiable
+ lower boundary, possibly extending to leaves. A subtree is always
+ defined within a context which implicitly bounds the subtree. For
+ example, the vertex and lower boundaries of a subtree defining a
+ replicated area are bounded by a naming context.
+
+
+3.2. Subentries
+
+ A subentry is a "special sort of entry, known by the Directory, used
+ to hold information associated with a subtree or subtree refinement"
+ [X.501]. Subentries are used in Directory to hold for administrative
+ and operational purposes as defined in [X.501]. Their use in LDAP is
+ detailed in [RFC3672].
+
+ The term "(sub)entry" in this specification indicates that servers
+ implementing X.500(93) models are, in accordance with X.500(93) as
+ described in [RFC3672], to use a subentry and that other servers are
+ to use an object entry belonging to the appropriate auxiliary class
+ normally used with the subentry (e.g., 'subschema' for subschema
+ subentries) to mimic the subentry. This object entry's RDN SHALL be
+ formed from a value of the 'cn' (commonName) attribute [Schema] (as
+ all subentries are named with 'cn').
+
+
+3.3. The 'objectClass' attribute
+
+ Each entry in the DIT has an 'objectClass' attribute.
+
+ ( 2.5.4.0 NAME 'objectClass'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+ The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER
+ (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [Syntaxes].
+
+ The 'objectClass' attribute specifies the object classes of an entry,
+ which (among other things) is used in conjunction with the controlling
+ schema to determine the permitted attributes of an entry. Values of
+ this attribute can be modified by clients, but the 'objectClass'
+ attribute cannot be removed.
+
+ Servers which follow X.500(93) models SHALL restrict modifications of
+ this attribute to prevent the basic structural class of the entry from
+
+
+
+Zeilenga LDAP Models [Page 18]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ being changed. That is, one cannot change a 'person' into a
+ 'country'.
+
+ When creating an entry or adding an 'objectClass' value to an entry,
+ all superclasses of the named classes SHALL be implicitly added as
+ well if not already present. That is, if the auxiliary class 'x-a' is
+ a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes
+ 'x-b' to be implicitly added (if is not already present).
+
+ Servers SHALL restrict modifications of this attribute to prevent
+ superclasses of remaining 'objectClass' values from being deleted.
+ That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
+ class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
+ an attempt to delete only 'x-b' from the 'objectClass' attribute is an
+ error.
+
+
+3.4. Operational attributes
+
+ Some attributes, termed operational attributes, are used or maintained
+ by servers for administrative and operational purposes. As stated in
+ [X.501]: "There are three varieties of operational attributes:
+ Directory operational attributes, DSA-shared operational attributes,
+ and DSA-specific operational attributes."
+
+ A directory operational attribute is used to represent operational
+ and/or administrative information in the Directory Information Model.
+ This includes operational attributes maintained by the server (e.g.
+ 'createTimestamp') as well as operational attributes which hold values
+ administrated by the user (e.g. 'ditContentRules').
+
+ A DSA-shared operational attribute is used to represent information of
+ the DSA Information Model which is shared between DSAs.
+
+ A DSA-specific operational attribute is used to represent information
+ of the DSA Information Model which is specific to the DSA (though, in
+ some cases, may be derived from information shared between DSAs)
+ (e.g., 'namingContexts').
+
+ The DSA Information Model operational attributes are detailed in
+ [X.501].
+
+ Operational attributes are not normally visible. They are not
+ returned in search results unless explicitly requested by name.
+
+ Not all operational attributes are user modifiable.
+
+ Entries may contain, among others, the following operational
+
+
+
+Zeilenga LDAP Models [Page 19]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ attributes:
+
+ - creatorsName: the Distinguished Name of the user who added this
+ entry to the directory,
+
+ - createTimestamp: the time this entry was added to the directory,
+
+ - modifiersName: the Distinguished Name of the user who last
+ modified this entry, and
+
+ - modifyTimestamp: the time this entry was last modified.
+
+ Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
+ 'modifiersName', and 'modifyTimestamp' attributes for all entries of
+ the DIT.
+
+
+3.4.1. 'creatorsName'
+
+ This attribute appears in entries which were added using the protocol
+ (e.g., using the Add operation). The value is the distinguished name
+ of the creator.
+
+ ( 2.5.18.3 NAME 'creatorsName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'distinguishedNameMatch' matching rule and the DistinguishedName
+ (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
+
+
+3.4.2. 'createTimestamp'
+
+ This attribute appears in entries which were added using the protocol
+ (e.g., using the Add operation). The value is the time the entry was
+ added.
+
+ ( 2.5.18.1 NAME 'createTimestamp'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
+ rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
+
+
+
+Zeilenga LDAP Models [Page 20]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ are defined in [Syntaxes].
+
+
+3.4.3. 'modifiersName'
+
+ This attribute appears in entries which have been modified using the
+ protocol (e.g., using Modify operation). The value is the
+ distinguished name of the last modifier.
+
+ ( 2.5.18.4 NAME 'modifiersName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'distinguishedNameMatch' matching rule and the DistinguishedName
+ (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
+
+
+3.4.4. 'modifyTimestamp'
+
+ This attribute appears in entries which have been modified using the
+ protocol (e.g., using the Modify operation). The value is the time
+ the entry was last modified.
+
+ ( 2.5.18.2 NAME 'modifyTimestamp'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
+ rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
+ are defined in [Syntaxes].
+
+
+3.4.5. 'structuralObjectClass'
+
+ This attribute indicates the structural object class of the entry.
+
+ ( 2.5.21.9 NAME 'structuralObjectClass'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
+
+
+
+Zeilenga LDAP Models [Page 21]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [Syntaxes].
+
+
+3.4.6. 'governingStructureRule'
+
+ This attribute indicates the structure rule governing the entry.
+
+ ( 2.5.21.10 NAME 'governingStructureRule'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'integerMatch' matching rule and INTEGER
+ (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [Syntaxes].
+
+
+4. Directory Schema
+
+ As defined in [X.501]:
+
+ The Directory Schema is a set of definitions and constraints
+ concerning the structure of the DIT, the possible ways entries are
+ named, the information that can be held in an entry, the
+ attributes used to represent that information and their
+ organization into hierarchies to facilitate search and retrieval
+ of the information and the ways in which values of attributes may
+ be matched in attribute value and matching rule assertions.
+
+ NOTE 1 - The schema enables the Directory system to, for example:
+
+ - prevent the creation of subordinate entries of the wrong
+ object-class (e.g. a country as a subordinate of a person);
+
+ - prevent the addition of attribute-types to an entry
+ inappropriate to the object-class (e.g. a serial number to a
+ person's entry);
+
+ - prevent the addition of an attribute value of a syntax not
+ matching that defined for the attribute-type (e.g. a printable
+ string to a bit string).
+
+ Formally, the Directory Schema comprises a set of:
+
+ a) Name Form definitions that define primitive naming relations
+ for structural object classes;
+
+ b) DIT Structure Rule definitions that define the names that
+
+
+
+Zeilenga LDAP Models [Page 22]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ entries may have and the ways in which the entries may be
+ related to one another in the DIT;
+
+ c) DIT Content Rule definitions that extend the specification of
+ allowable attributes for entries beyond those indicated by the
+ structural object classes of the entries;
+
+ d) Object Class definitions that define the basic set of mandatory
+ and optional attributes that shall be present, and may be
+ present, respectively, in an entry of a given class, and which
+ indicate the kind of object class that is being defined;
+
+ e) Attribute Type definitions that identify the object identifier
+ by which an attribute is known, its syntax, associated matching
+ rules, whether it is an operational attribute and if so its
+ type, whether it is a collective attribute, whether it is
+ permitted to have multiple values and whether or not it is
+ derived from another attribute type;
+
+ f) Matching Rule definitions that define matching rules.
+
+ And in LDAP:
+
+ g) LDAP Syntax definitions that define encodings used in LDAP.
+
+
+4.1. Schema Definitions
+
+ Schema definitions in this section are described using ABNF and rely
+ on the common productions specified in Section 1.2 as well as these:
+
+ noidlen = numericoid [ LCURLY len RCURLY ]
+ len = number
+
+ oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
+ oidlist = oid *( WSP DOLLAR WSP oid )
+
+ extensions = *( SP xstring SP qdstrings )
+ xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
+
+ qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
+ qdescrlist = [ qdescr *( SP qdescr ) ]
+ qdescr = SQUOTE descr SQUOTE
+
+ qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
+ qdstringlist = [ qdstring *( SP qdstring ) ]
+ qdstring = SQUOTE dstring SQUOTE
+ dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string
+
+
+
+Zeilenga LDAP Models [Page 23]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ QQ = ESC %x32 %x37 ; "\27"
+ QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
+
+ ; Any UTF-8 encoded Unicode character
+ ; except %x27 ("'") and %x5C ("\")
+ QUTF8 = QUTF1 / UTFMB
+
+ ; Any ASCII character except %x27 ("'") and %x5C ("\")
+ QUTF1 = %x00-26 / %x28-5B / %x5D-7F
+
+ Schema definitions in this section also share a number of common
+ terms.
+
+ The NAME field provides a set of short names (descriptors) which are
+ to be used as aliases for the OID.
+
+ The DESC field optionally allows a descriptive string to be provided
+ by the directory administrator and/or implementor. While
+ specifications may suggest a descriptive string, there is no
+ requirement that the suggested (or any) descriptive string be used.
+
+ The OBSOLETE field, if present, indicates the element is not active.
+
+ Implementors should note that future versions of this document may
+ expand these definitions to include additional terms. Terms whose
+ identifier begins with "X-" are reserved for private experiments, and
+ are followed by <SP> and <qdstrings> tokens.
+
+
+4.1.1. Object Class Definitions
+
+ Object Class definitions are written according to the ABNF:
+
+ ObjectClassDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ [ SP "SUP" SP oids ] ; superior object classes
+ [ SP kind ] ; kind of class
+ [ SP "MUST" SP oids ] ; attribute types
+ [ SP "MAY" SP oids ] ; attribute types
+ extensions WSP RPAREN
+
+ kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
+
+ where:
+ <numericoid> is object identifier assigned to this object class;
+
+
+
+Zeilenga LDAP Models [Page 24]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ NAME <qdescrs> are short names (descriptors) identifying this object
+ class;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this object class is not active;
+ SUP <oids> specifies the direct superclasses of this object class;
+ the kind of object class is indicated by one of ABSTRACT,
+ STRUCTURAL, or AUXILIARY, default is STRUCTURAL;
+ MUST and MAY specify the sets of required and allowed attribute
+ types, respectively; and
+ <extensions> describe extensions.
+
+
+4.1.2. Attribute Types
+
+ Attribute Type definitions are written according to the ABNF:
+
+ AttributeTypeDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ [ SP "SUP" SP oid ] ; supertype
+ [ SP "EQUALITY" SP oid ] ; equality matching rule
+ [ SP "ORDERING" SP oid ] ; ordering matching rule
+ [ SP "SUBSTR" SP oid ] ; substrings matching rule
+ [ SP "SYNTAX" SP noidlen ] ; value syntax
+ [ SP "SINGLE-VALUE" ] ; single-value
+ [ SP "COLLECTIVE" ] ; collective
+ [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
+ [ SP "USAGE" SP usage ] ; usage
+ extensions WSP RPAREN ; extensions
+
+ usage = "userApplications" / ; user
+ "directoryOperation" / ; directory operational
+ "distributedOperation" / ; DSA-shared operational
+ "dSAOperation" ; DSA-specific operational
+
+ where:
+ <numericoid> is object identifier assigned to this attribute type;
+ NAME <qdescrs> are short names (descriptors) identifying this
+ attribute type;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this attribute type is not active;
+ SUP oid specifies the direct supertype of this type;
+ EQUALITY, ORDERING, SUBSTR provide the oid of the equality,
+ ordering, and substrings matching rules, respectively;
+ SYNTAX identifies value syntax by object identifier and may suggest
+ a minimum upper bound;
+
+
+
+Zeilenga LDAP Models [Page 25]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ SINGLE-VALUE indicates attributes of this type are restricted to a
+ single value;
+ COLLECTIVE indicates this attribute type is collective
+ [X.501][RFC3671];
+ NO-USER-MODIFICATION indicates this attribute type is not user
+ modifiable;
+ USAGE indicates the application of this attribute type; and
+ <extensions> describe extensions.
+
+ Each attribute type description must contain at least one of the SUP
+ or SYNTAX fields. If no SYNTAX field is provided, the attribute type
+ description takes its value from the supertype.
+
+ If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
+ fields, if not specified, take their value from the supertype.
+
+ Usage of userApplications, the default, indicates that attributes of
+ this type represent user information. That is, they are user
+ attributes.
+
+ A usage of directoryOperation, distributedOperation, or dSAOperation
+ indicates that attributes of this type represent operational and/or
+ administrative information. That is, they are operational attributes.
+
+ directoryOperation usage indicates that the attribute of this type is
+ a directory operational attribute. distributedOperation usage
+ indicates that the attribute of this DSA-shared usage operational
+ attribute. dSAOperation usage indicates that the attribute of this
+ type is a DSA-specific operational attribute.
+
+ COLLECTIVE requires usage userApplications. Use of collective
+ attribute types in LDAP is discussed in [RFC3671].
+
+ NO-USER-MODIFICATION requires an operational usage.
+
+ Note that the <AttributeTypeDescription> does not list the matching
+ rules which can be used with that attribute type in an extensibleMatch
+ search filter [Protocol]. This is done using the 'matchingRuleUse'
+ attribute described in Section 4.1.4.
+
+ This document refines the schema description of X.501 by requiring
+ that the SYNTAX field in an <AttributeTypeDescription> be a string
+ representation of an object identifier for the LDAP string syntax
+ definition with an optional indication of the suggested minimum bound
+ of a value of this attribute.
+
+ A suggested minimum upper bound on the number of characters in a value
+ with a string-based syntax, or the number of bytes in a value for all
+
+
+
+Zeilenga LDAP Models [Page 26]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ other syntaxes, may be indicated by appending this bound count inside
+ of curly braces following the syntax's OBJECT IDENTIFIER in an
+ Attribute Type Description. This bound is not part of the syntax name
+ itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that server
+ implementations should allow a string to be 64 characters long,
+ although they may allow longer strings. Note that a single character
+ of the Directory String syntax may be encoded in more than one octet
+ since UTF-8 [RFC3629] is a variable-length encoding.
+
+
+4.1.3. Matching Rules
+
+ Matching rules are used in performance of attribute value assertions,
+ such as in performance of a Compare operation. They are also used in
+ evaluation of a Search filters, in determining which individual values
+ are be added or deleted during performance of a Modify operation, and
+ used in comparison of distinguished names.
+
+ Each matching rule is identified by an object identifier (OID) and,
+ optionally, one or more short names (descriptors).
+
+ Matching rule definitions are written according to the ABNF:
+
+ MatchingRuleDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ SP "SYNTAX" SP numericoid ; assertion syntax
+ extensions WSP RPAREN ; extensions
+
+ where:
+ <numericoid> is object identifier assigned to this matching rule;
+ NAME <qdescrs> are short names (descriptors) identifying this
+ matching rule;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this matching rule is not active;
+ SYNTAX identifies the assertion syntax (the syntax of the assertion
+ value) by object identifier; and
+ <extensions> describe extensions.
+
+
+4.1.4. Matching Rule Uses
+
+ A matching rule use lists the attribute types which are suitable for
+ use with an extensibleMatch search filter.
+
+ Matching rule use descriptions are written according to the following
+
+
+
+Zeilenga LDAP Models [Page 27]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ ABNF:
+
+ MatchingRuleUseDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ SP "APPLIES" SP oids ; attribute types
+ extensions WSP RPAREN ; extensions
+
+ where:
+ <numericoid> is the object identifier of the matching rule
+ associated with this matching rule use description;
+ NAME <qdescrs> are short names (descriptors) identifying this
+ matching rule use;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this matching rule use is not active;
+ APPLIES provides a list of attribute types the matching rule applies
+ to; and
+ <extensions> describe extensions.
+
+
+4.1.5. LDAP Syntaxes
+
+ LDAP Syntaxes of (attribute and assertion) values are described in
+ terms of ASN.1 [X.680] and, optionally, have an octet string encoding
+ known as the LDAP-specific encoding. Commonly, the LDAP-specific
+ encoding is constrained to a string of Unicode [Unicode] characters in
+ UTF-8 [RFC3629] form.
+
+ Each LDAP syntax is identified by an object identifier (OID).
+
+ LDAP syntax definitions are written according to the ABNF:
+
+ SyntaxDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "DESC" SP qdstring ] ; description
+ extensions WSP RPAREN ; extensions
+
+ where:
+ <numericoid> is the object identifier assigned to this LDAP syntax;
+ DESC <qdstring> is a short descriptive string; and
+ <extensions> describe extensions.
+
+
+4.1.6. DIT Content Rules
+
+ A DIT content rule is a "rule governing the content of entries of a
+
+
+
+Zeilenga LDAP Models [Page 28]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ particular structural object class" [X.501].
+
+ For DIT entries of a particular structural object class, a DIT content
+ rule specifies which auxiliary object classes the entries are allowed
+ to belong to and which additional attributes (by type) are required,
+ allowed or not allowed to appear in the entries.
+
+ The list of precluded attributes cannot include any attribute listed
+ as mandatory in the rule, the structural object class, or any of the
+ allowed auxiliary object classes.
+
+ Each content rule is identified by the object identifier, as well as
+ any short names (descriptors), of the structural object class it
+ applies to.
+
+ An entry may only belong to auxiliary object classes listed in the
+ governing content rule.
+
+ An entry must contain all attributes required by the object classes
+ the entry belongs to as well as all attributes required by the
+ governing content rule.
+
+ An entry may contain any non-precluded attributes allowed by the
+ object classes the entry belongs to as well as all attributes allowed
+ by the governing content rule.
+
+ An entry cannot include any attribute precluded by the governing
+ content rule.
+
+ An entry is governed by (if present and active in the subschema) the
+ DIT content rule which applies to the structural object class of the
+ entry (see Section 2.4.2). If no active rule is present for the
+ entry's structural object class, the entry's content is governed by
+ the structural object class (and possibly other aspects of user and
+ system schema). DIT content rules for superclasses of the structural
+ object class of an entry are not applicable to that entry.
+
+ DIT content rule descriptions are written according to the ABNF:
+
+ DITContentRuleDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ [ SP "AUX" SP oids ] ; auxiliary object classes
+ [ SP "MUST" SP oids ] ; attribute types
+ [ SP "MAY" SP oids ] ; attribute types
+ [ SP "NOT" SP oids ] ; attribute types
+
+
+
+Zeilenga LDAP Models [Page 29]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ extensions WSP RPAREN ; extensions
+
+ where:
+ <numericoid> is the object identifier of the structural object class
+ associated with this DIT content rule;
+ NAME <qdescrs> are short names (descriptors) identifying this DIT
+ content rule;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this DIT content rule use is not active;
+ AUX specifies a list of auxiliary object classes which entries
+ subject to this DIT content rule may belong to;
+ MUST, MAY, and NOT specify lists of attribute types which are
+ required, allowed, or precluded, respectively, from appearing in
+ entries subject to this DIT content rule; and
+ <extensions> describe extensions.
+
+
+4.1.7. DIT Structure Rules and Name Forms
+
+ It is sometimes desirable to regulate where object and alias entries
+ can be placed in the DIT and how they can be named based upon their
+ structural object class.
+
+
+4.1.7.1. DIT Structure Rules
+
+ A DIT structure rule is a "rule governing the structure of the DIT by
+ specifying a permitted superior to subordinate entry relationship. A
+ structure rule relates a name form, and therefore a structural object
+ class, to superior structure rules. This permits entries of the
+ structural object class identified by the name form to exist in the
+ DIT as subordinates to entries governed by the indicated superior
+ structure rules" [X.501].
+
+ DIT structure rule descriptions are written according to the ABNF:
+
+ DITStructureRuleDescription = LPAREN WSP
+ ruleid ; rule identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ SP "FORM" SP oid ; NameForm
+ [ SP "SUP" ruleids ] ; superior rules
+ extensions WSP RPAREN ; extensions
+
+ ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
+ ruleidlist = ruleid *( SP ruleid )
+ ruleid = number
+
+
+
+Zeilenga LDAP Models [Page 30]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ where:
+ <ruleid> is the rule identifier of this DIT structure rule;
+ NAME <qdescrs> are short names (descriptors) identifying this DIT
+ structure rule;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this DIT structure rule use is not active;
+ FORM is specifies the name form associated with this DIT structure
+ rule;
+ SUP identifies superior rules (by rule id); and
+ <extensions> describe extensions.
+
+ If no superior rules are identified, the DIT structure rule applies
+ to an autonomous administrative point (e.g. the root vertex of the
+ subtree controlled by the subschema) [X.501].
+
+
+4.1.7.2. Name Forms
+
+ A name form "specifies a permissible RDN for entries of a particular
+ structural object class. A name form identifies a named object
+ class and one or more attribute types to be used for naming (i.e.
+ for the RDN). Name forms are primitive pieces of specification
+ used in the definition of DIT structure rules" [X.501].
+
+ Each name form indicates the structural object class to be named,
+ a set of required attribute types, and a set of allowed attribute
+ types. A particular attribute type cannot be in both sets.
+
+ Entries governed by the form must be named using a value from each
+ required attribute type and zero or more values from the allowed
+ attribute types.
+
+ Each name form is identified by an object identifier (OID) and,
+ optionally, one or more short names (descriptors).
+
+ Name form descriptions are written according to the ABNF:
+
+ NameFormDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ SP "OC" SP oid ; structural object class
+ SP "MUST" SP oids ; attribute types
+ [ SP "MAY" SP oids ] ; attribute types
+ extensions WSP RPAREN ; extensions
+
+ where:
+
+
+
+Zeilenga LDAP Models [Page 31]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ <numericoid> is object identifier which identifies this name form;
+ NAME <qdescrs> are short names (descriptors) identifying this name
+ form;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this name form is not active;
+ OC identifies the structural object class this rule applies to,
+ MUST and MAY specify the sets of required and allowed, respectively,
+ naming attributes for this name form; and
+ <extensions> describe extensions.
+
+ All attribute types in the required ("MUST") and allowed ("MAY") lists
+ shall be different.
+
+
+4.2. Subschema Subentries
+
+ Subschema (sub)entries are used for administering information about
+ the directory schema. A single subschema (sub)entry contains all
+ schema definitions (see Section 4.1) used by entries in a particular
+ part of the directory tree.
+
+ Servers which follow X.500(93) models SHOULD implement subschema using
+ the X.500 subschema mechanisms (as detailed in Section 12 of [X.501]),
+ and so these are not ordinary object entries but subentries (see
+ Section 3.2). LDAP clients SHOULD NOT assume that servers implement
+ any of the other aspects of X.500 subschema.
+
+ Servers MAY allow subschema modification. Procedures for subschema
+ modification are discussed in Section 14.5 of [X.501].
+
+ A server which masters entries and permits clients to modify these
+ entries SHALL implement and provide access to these subschema
+ (sub)entries including providing a 'subschemaSubentry' attribute in
+ each modifiable entry. This is so clients may discover the attributes
+ and object classes which are permitted to be present. It is strongly
+ RECOMMENDED that all other servers implement this as well.
+
+ The value of the 'subschemaSubentry' attribute is the name of the
+ subschema (sub)entry holding the subschema controlling the entry.
+
+ ( 2.5.18.10 NAME 'subschemaSubentry'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ NO-USER-MODIFICATION SINGLE-VALUE
+ USAGE directoryOperation )
+
+ The 'distinguishedNameMatch' matching rule and the DistinguishedName
+ (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
+
+
+
+Zeilenga LDAP Models [Page 32]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ Subschema is held in (sub)entries belonging to the subschema auxiliary
+ object class.
+
+ ( 2.5.20.1 NAME 'subschema' AUXILIARY
+ MAY ( dITStructureRules $ nameForms $ ditContentRules $
+ objectClasses $ attributeTypes $ matchingRules $
+ matchingRuleUse ) )
+
+ The 'ldapSyntaxes' operational attribute may also be present in
+ subschema entries.
+
+ Servers MAY provide additional attributes (described in other
+ documents) in subschema (sub)entries.
+
+ Servers SHOULD provide the attributes 'createTimestamp' and
+ 'modifyTimestamp' in subschema (sub)entries, in order to allow clients
+ to maintain their caches of schema information.
+
+ The following subsections provide attribute type definitions for each
+ of schema definition attribute types.
+
+
+4.2.1. 'objectClasses'
+
+ This attribute holds definitions of object classes.
+
+ ( 2.5.21.6 NAME 'objectClasses'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
+ defined in [Syntaxes].
+
+
+4.2.2. 'attributeTypes'
+
+ This attribute holds definitions of attribute types.
+
+ ( 2.5.21.5 NAME 'attributeTypes'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
+ defined in [Syntaxes].
+
+
+
+Zeilenga LDAP Models [Page 33]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+4.2.3. 'matchingRules'
+
+ This attribute holds definitions of matching rules.
+
+ ( 2.5.21.4 NAME 'matchingRules'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
+ defined in [Syntaxes].
+
+
+4.2.4 'matchingRuleUse'
+
+ This attribute holds definitions of matching rule uses.
+
+ ( 2.5.21.8 NAME 'matchingRuleUse'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
+ defined in [Syntaxes].
+
+
+4.2.5. 'ldapSyntaxes'
+
+ This attribute holds definitions of LDAP syntaxes.
+
+ ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
+ in [Syntaxes].
+
+
+4.2.6. 'dITContentRules'
+
+ This attribute lists DIT Content Rules which are present in the
+ subschema.
+
+ ( 2.5.21.2 NAME 'dITContentRules'
+
+
+
+Zeilenga LDAP Models [Page 34]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
+ defined in [Syntaxes].
+
+
+4.2.7. 'dITStructureRules'
+
+ This attribute lists DIT Structure Rules which are present in the
+ subschema.
+
+ ( 2.5.21.1 NAME 'dITStructureRules'
+ EQUALITY integerFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
+ USAGE directoryOperation )
+
+ The 'integerFirstComponentMatch' matching rule and the
+ DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax are
+ defined in [Syntaxes].
+
+
+4.2.8 'nameForms'
+
+ This attribute lists Name Forms which are in force.
+
+ ( 2.5.21.7 NAME 'nameForms'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are defined
+ in [Syntaxes].
+
+
+4.3. 'extensibleObject' object class
+
+ The 'extensibleObject' auxiliary object class allows entries that
+ belong to it to hold any user attribute. The set of allowed attribute
+ types of this object class is implicitly the set of all attribute
+ types of userApplications usage.
+
+ ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
+ SUP top AUXILIARY )
+
+
+
+
+Zeilenga LDAP Models [Page 35]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ The mandatory attributes of the other object classes of this entry are
+ still required to be present and any precluded attributes are still
+ not allowed to be present.
+
+
+
+4.4. Subschema Discovery
+
+ To discover the DN of the subschema (sub)entry holding the subschema
+ controlling a particular entry, a client reads that entry's
+ 'subschemaSubentry' operational attribute. To read schema attributes
+ from the subschema (sub)entry, clients MUST issue a Search operation
+ [Protocol] where baseObject is the DN of the subschema (sub)entry,
+ scope is baseObject, filter is "(objectClass=subschema)" [Filters],
+ and attributes field lists the names of the desired schema attributes
+ (as they are operational). Note: the "(objectClass=subschema)" filter
+ allows LDAP servers which gateway to X.500 to detect that subentry
+ information is being requested.
+
+ Clients SHOULD NOT assume a published subschema is complete nor assume
+ the server supports all of the schema elements it publishes nor assume
+ the server does not support an unpublished element.
+
+
+5. DSA (Server) Informational Model
+
+ The LDAP protocol assumes there are one or more servers which jointly
+ provide access to a Directory Information Tree (DIT). The server
+ holding the original information is called the "master" (for that
+ information). Servers which hold copies of the original information
+ are referred to as "shadowing" or "caching" servers.
+
+ As defined in [X.501]:
+
+ context prefix: The sequence of RDNs leading from the Root of the
+ DIT to the initial vertex of a naming context; corresponds to
+ the distinguished name of that vertex.
+
+ and:
+
+ naming context: A subtree of entries held in a single master DSA.
+
+ That is, a naming context is the largest collection of entries,
+ starting at an entry that is mastered by a particular server, and
+ including all its subordinates and their subordinates, down to the
+ entries which are mastered by different servers. The context prefix
+ is the name of the initial entry.
+
+
+
+
+Zeilenga LDAP Models [Page 36]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ The root of the DIT is a DSA-specific Entry (DSE) and not part of any
+ naming context (or any subtree); each server has different attribute
+ values in the root DSE.
+
+
+5.1. Server-specific Data Requirements
+
+ An LDAP server SHALL provide information about itself and other
+ information that is specific to each server. This is represented as a
+ group of attributes located in the root DSE, which is named with the
+ DN with zero RDNs (whose [LDAPDN] representation is as the zero-length
+ string).
+
+ These attributes are retrievable, subject to access control and other
+ restrictions, if a client performs a Search operation [Protocol] with
+ an empty baseObject, scope of baseObject, the filter "(objectClass=*)"
+ [Filters], and with the attributes field listing the names of the
+ desired attributes. It is noted that root DSE attributes are
+ operational, and like other operational attributes, are not returned
+ in search requests unless requested by name.
+
+ The root DSE SHALL NOT be included if the client performs a subtree
+ search starting from the root.
+
+ Servers may allow clients to modify attributes of the root DSE where
+ appropriate.
+
+ The following attributes of the root DSE are defined in [Syntaxes].
+ Additional attributes may be defined in other documents.
+
+ - altServer: alternative servers;
+
+ - namingContexts: naming contexts;
+
+ - supportedControl: recognized LDAP controls;
+
+ - supportedExtension: recognized LDAP extended operations;
+
+ - supportedFeatures: recognized LDAP features;
+
+ - supportedLDAPVersion: LDAP versions supported; and
+
+ - supportedSASLMechanisms: recognized Simple Authentication and
+ Security Layers (SASL) [SASL] mechanisms.
+
+ The values provided for these attributes may depend on
+ session-specific and other factors. For example, a server supporting
+ the SASL EXTERNAL mechanism might only list "EXTERNAL" when the
+
+
+
+Zeilenga LDAP Models [Page 37]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ client's identity has been established by a lower level. See
+ [AuthMeth].
+
+ The root DSE may also include a 'subschemaSubentry' attribute. If so,
+ it refers to the subschema (sub)entry holding the schema controlling
+ the root DSE. Clients SHOULD NOT assume that this subschema
+ (sub)entry controls other entries held by the server. General
+ subschema discovery procedures are provided in Section 4.4.
+
+
+5.1.1. 'altServer'
+
+ The 'altServer' attribute lists URIs referring to alternative servers
+ which may be contacted when this server becomes unavailable. URIs for
+ servers implementing the LDAP are written according to [LDAPURL].
+ Other kinds of URIs may be provided. If the server does not know of
+ any other servers which could be used this attribute will be absent.
+ Clients may cache this information in case their preferred server
+ later becomes unavailable.
+
+ ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ USAGE dSAOperation )
+
+ The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
+ [Syntaxes].
+
+
+5.1.2. 'namingContexts'
+
+ The 'namingContexts' attribute lists the context prefixes of the
+ naming contexts the server masters or shadows (in part or in whole).
+ If the server is a first-level DSA [X.501], it should list (in
+ addition) an empty string (indicating the root of the DIT). If the
+ server does not master or shadow any information (e.g. it is an LDAP
+ gateway to a public X.500 directory) this attribute will be absent.
+ If the server believes it masters or shadows the entire directory, the
+ attribute will have a single value, and that value will be the empty
+ string (indicating the root of the DIT).
+
+ This attribute may be used, for example, to select a suitable entry
+ name for subsequent operations with this server.
+
+ ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ USAGE dSAOperation )
+
+ The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
+
+
+
+Zeilenga LDAP Models [Page 38]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ defined in [Syntaxes].
+
+
+5.1.3. 'supportedControl'
+
+ The 'supportedControl' attribute lists object identifiers identifying
+ the request controls [Protocol] the server supports. If the server
+ does not support any request controls, this attribute will be absent.
+ Object identifiers identifying response controls need not be listed.
+
+ Procedures for registering object identifiers used to discovery of
+ protocol mechanisms are detailed in BCP 64 [BCP64bis].
+
+ ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE dSAOperation )
+
+ The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
+ defined in [Syntaxes].
+
+
+5.1.4. 'supportedExtension'
+
+ The 'supportedExtension' attribute lists object identifiers
+ identifying the extended operations [Protocol] which the server
+ supports. If the server does not support any extended operations,
+ this attribute will be absent.
+
+ An extended operation generally consists of an extended request and an
+ extended response but may also include other protocol data units (such
+ as intermediate responses). The object identifier assigned to the
+ extended request is used to identify the extended operation. Other
+ object identifiers used in the extended operation need not be listed
+ as values of this attribute.
+
+ Procedures for registering object identifiers used to discovery of
+ protocol mechanisms are detailed in BCP 64 [BCP64bis].
+
+ ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE dSAOperation )
+
+ The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
+ defined in [Syntaxes].
+
+
+5.1.5. 'supportedFeatures'
+
+
+
+
+Zeilenga LDAP Models [Page 39]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ The 'supportedFeatures' attribute lists object identifiers identifying
+ elective features which the server supports. If the server does not
+ support any discoverable elective features, this attribute will be
+ absent.
+
+ ( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE dSAOperation )
+
+ Procedures for registering object identifiers used to discovery of
+ protocol mechanisms are detailed in BCP 64 [BCP64bis].
+
+ The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and
+ objectIdentifierMatch matching rule are defined in [Syntaxes].
+
+
+5.1.6. 'supportedLDAPVersion'
+
+ The 'supportedLDAPVersion' attribute lists the versions of LDAP which
+ the server supports.
+
+ ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ USAGE dSAOperation )
+
+ The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax are defined in
+ [Syntaxes].
+
+
+5.1.7. 'supportedSASLMechanisms'
+
+ The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
+ [SASL] which the server recognizes and/or supports [AuthMeth]. The
+ contents of this attribute may depend on the current session state.
+ If the server does not support any SASL mechanisms this attribute will
+ not be present.
+
+ ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ USAGE dSAOperation )
+
+ The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is defined
+ in [Syntaxes].
+
+
+6. Other Considerations
+
+
+
+
+Zeilenga LDAP Models [Page 40]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+6.1. Preservation of User Information
+
+ Syntaxes may be defined which have specific value and/or value form
+ (representation) preservation requirements. For example, a syntax
+ containing digitally signed data can mandate the server preserve both
+ the value and form of value presented to ensure signature is not
+ invalidated.
+
+ Where such requirements have not been explicitly stated, servers
+ SHOULD preserve the value of user information but MAY return the value
+ in a different form. And where a server is unable (or unwilling) to
+ preserve the value of user information, the server SHALL ensure that
+ an equivalent value (per Section 2.3) is returned.
+
+
+6.2. Short Names
+
+ Short names, also known as descriptors, are used as more readable
+ aliases for object identifiers and are used to identify various schema
+ elements. However, it is not expected that LDAP implementations with
+ human user interface would display these short names (nor the object
+ identifiers they refer to) to the user, but would most likely be
+ performing translations (such as expressing the short name in one of
+ the local national languages). For example, the short name "st"
+ (stateOrProvinceName) might be displayed to a German-speaking user as
+ "Land".
+
+ The same short name might have different meaning in different
+ subschemas and, within a particular subschema, the same short name
+ might refer to different object identifiers each identifying a
+ different kind of schema element.
+
+ Implementations MUST be prepared that the same short name might be
+ used in a subschema to refer to the different kinds of schema
+ elements. That is, there might be an object class 'x-fubar' and an
+ attribute type 'x-fubar' in a subschema.
+
+ Implementations MUST be prepared that the same short name might be
+ used in the different subschemas to refer to the different schema
+ elements. That is, there might be two matching rules 'x-fubar', each
+ in different subschemas.
+
+ Procedures for registering short names (descriptors) are detailed in
+ BCP 64 [BCP64bis].
+
+
+6.3. Cache and Shadowing
+
+
+
+
+Zeilenga LDAP Models [Page 41]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ Some servers may hold cache or shadow copies of entries, which can be
+ used to answer search and comparison queries, but will return
+ referrals or contact other servers if modification operations are
+ requested. Servers that perform shadowing or caching MUST ensure that
+ they do not violate any access control constraints placed on the data
+ by the originating server.
+
+
+7. Implementation Guidelines
+
+7.1 Server Guidelines
+
+ Servers MUST recognize all names of attribute types and object classes
+ defined in this document but, unless stated otherwise, need not
+ support the associated functionality. Servers SHOULD recognize all
+ the names of attribute types and object classes defined in Section 3
+ and 4, respectively, of [Schema].
+
+ Servers MUST ensure that entries conform to user and system schema
+ rules or other data model constraints.
+
+ Servers MAY support DIT Content Rules. Servers MAY support DIT
+ Structure Rules and Name Forms.
+
+ Servers MAY support alias entries.
+
+ Servers MAY support the 'extensibleObject' object class.
+
+ Servers MAY support subentries. If so, they MUST do so in accordance
+ with [RFC3672]. Servers which do not support subentries SHOULD use
+ object entries to mimic subentries as detailed in Section 3.2.
+
+ Servers MAY implement additional schema elements. Servers SHOULD
+ provide definitions of all schema elements they support in subschema
+ (sub)entries.
+
+
+7.2 Client Guidelines
+
+ In the absence of prior agreements with servers, clients SHOULD NOT
+ assume that servers support any particular schema elements beyond
+ those referenced in Section 7.1. The client can retrieve subschema
+ information as described in Section 4.4.
+
+ Clients MUST NOT display nor attempt to decode as ASN.1, a value if
+ its syntax is not known. Clients MUST NOT assume the LDAP-specific
+ string encoding is restricted to a UTF-8 encoded string of Unicode
+ characters or any particular subset of Unicode (such as a printable
+
+
+
+Zeilenga LDAP Models [Page 42]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ subset) unless such restriction is explicitly stated. Clients SHOULD
+ NOT send attribute values in a request that are not valid according to
+ the syntax defined for the attributes.
+
+
+8. Security Considerations
+
+ Attributes of directory entries are used to provide descriptive
+ information about the real-world objects they represent, which can be
+ people, organizations or devices. Most countries have privacy laws
+ regarding the publication of information about people.
+
+ General security considerations for accessing directory information
+ with LDAP are discussed in [Protocol] and [AuthMeth].
+
+
+9. IANA Considerations
+
+ It is requested that the Internet Assigned Numbers Authority (IANA)
+ update the LDAP descriptors registry as indicated in the following
+ template:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comment
+ Object Identifier: see comment
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Usage: see comment
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+
+ The following descriptors (short names) should be added to
+ the registry.
+
+ NAME Type OID
+ ------------------------ ---- -----------------
+ governingStructureRule A 2.5.21.10
+ structuralObjectClass A 2.5.21.9
+
+ The following descriptors (short names) should be updated to
+ refer to this RFC.
+
+ NAME Type OID
+ ------------------------ ---- -----------------
+ alias O 2.5.6.1
+ aliasedObjectName A 2.5.4.1
+ altServer A 1.3.6.1.4.1.1466.101.120.6
+
+
+
+Zeilenga LDAP Models [Page 43]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ attributeTypes A 2.5.21.5
+ createTimestamp A 2.5.18.1
+ creatorsName A 2.5.18.3
+ dITContentRules A 2.5.21.2
+ dITStructureRules A 2.5.21.1
+ extensibleObject O 1.3.6.1.4.1.1466.101.120.111
+ ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
+ matchingRuleUse A 2.5.21.8
+ matchingRules A 2.5.21.4
+ modifiersName A 2.5.18.4
+ modifyTimestamp A 2.5.18.2
+ nameForms A 2.5.21.7
+ namingContexts A 1.3.6.1.4.1.1466.101.120.5
+ objectClass A 2.5.4.0
+ objectClasses A 2.5.21.6
+ subschema O 2.5.20.1
+ subschemaSubentry A 2.5.18.10
+ supportedControl A 1.3.6.1.4.1.1466.101.120.13
+ supportedExtension A 1.3.6.1.4.1.1466.101.120.7
+ supportedFeatures A 1.3.6.1.4.1.4203.1.3.5
+ supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
+ supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
+ top O 2.5.6.0
+
+
+10. Acknowledgments
+
+ This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
+ S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
+ RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
+ Indexing of Directories (ASID) Working Group. This document is also
+ based in part on "The Directory: Models" [X.501], a product of the
+ International Telephone Union (ITU). Additional text was borrowed
+ from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
+
+ This document is a product of the IETF LDAP Revision (LDAPBIS) Working
+ Group.
+
+
+11. Editor's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt at OpenLDAP.org
+
+
+12. References
+
+
+
+Zeilenga LDAP Models [Page 44]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 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.]]
+
+
+12.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.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 3629 (also STD 63), November 2003.
+
+ [RFC3671] Zeilenga, K., "Collective Attributes in LDAP", RFC 3671,
+ December 2003.
+
+ [RFC3672] Zeilenga, K. and S. Legg, "Subentries in LDAP", RFC
+ 3672, December 2003.
+
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+
+ [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.
+
+ [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
+ Representation of Search Filters",
+ draft-ietf-ldapbis-filter-xx.txt, a work in progress.
+
+ [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
+ work in progress.
+
+ [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
+ draft-ietf-ldapbis-url-xx.txt, a work in progress.
+
+ [SASL] Melnikov, A. (Editor), "Simple Authentication and
+
+
+
+Zeilenga LDAP Models [Page 45]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ Security Layer (SASL)",
+ draft-ietf-sasl-rfc2222bis-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.
+
+ [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/).
+
+ [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.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).
+
+
+12.2. Informative References
+
+ None.
+
+
+Appendix A. Changes
+
+ This appendix is non-normative.
+
+ This document amounts to nearly a complete rewrite of portions of RFC
+ 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve
+ overall clarity of technical specification. This appendix provides a
+ summary of substantive changes made to the portions of these documents
+ incorporated into this document. Readers should consult [Roadmap],
+ [Protocol], [Syntaxes], and [Schema] for summaries of remaining
+
+
+
+Zeilenga LDAP Models [Page 46]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ portions of these documents.
+
+
+A.1 Changes to RFC 2251
+
+ This document incorporates from RFC 2251 sections 3.2 and 3.4,
+ portions of Section 4 and 6 as summarized below.
+
+
+A.1.1 Section 3.2 of RFC 2251
+
+ Section 3.2 of RFC 2251 provided a brief introduction to the X.500
+ data model, as used by LDAP. The previous specification relied on
+ [X.501] but lacked clarity in how X.500 models are adapted for use by
+ LDAP. This document describes the X.500 data models, as used by LDAP
+ in greater detail, especially in areas where adaptation is needed.
+
+ Section 3.2.1 of RFC 2251 described an attribute as "a type with one
+ or more associated values." In LDAP, an attribute is better described
+ as an attribute description, a type with zero or more options, and one
+ or more associated values.
+
+ Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
+ objectClasses and attributeTypes attributes, yet X.500(93) treats
+ these attributes as optional. While generally all implementations
+ that support X.500(93) subschema mechanisms will provide both of these
+ attributes, it is not absolutely required for interoperability that
+ all servers do. The mandate was removed for consistency with
+ X.500(93). The subschema discovery mechanism was also clarified to
+ indicate that subschema controlling an entry is obtained by reading
+ the (sub)entry referred to by that entry's 'subschemaSubentry'
+ attribute.
+
+
+A.1.2 Section 3.4 of RFC 2251
+
+ Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
+ This material, with changes, was incorporated in Section 5.1 of this
+ document.
+
+ Changes:
+
+ - Clarify that attributes of the root DSE are subject to "other
+ restrictions" in addition to access controls.
+
+ - Clarify that only recognized extended requests need to be enumerated
+ 'supportedExtension'.
+
+
+
+
+Zeilenga LDAP Models [Page 47]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ - Clarify that only recognized request controls need to be enumerated
+ 'supportedControl'.
+
+ - Clarify that root DSE attributes are operational and, like other
+ operational attributes, will not be returned in search requests
+ unless requested by name.
+
+ - Clarify that not all root DSE attributes are user modifiable.
+
+ - Remove inconsistent text regarding handling of the
+ 'subschemaSubentry' attribute within the root DSE. The previous
+ specification stated that the 'subschemaSubentry' attribute held in
+ the root DSE referred to "subschema entries (or subentries) known by
+ this server." This is inconsistent with the attribute intended use
+ as well as its formal definition as a single valued attribute
+ [X.501]. It is also noted that a simple (possibly incomplete) list
+ of subschema (sub)entries is not terrible useful. This document (in
+ section 5.1) specifies that the 'subschemaSubentry' attribute of the
+ root DSE refers to the subschema controlling the root DSE. It is
+ noted that the general subschema discovery mechanism remains
+ available (see Section 4.4 of this document).
+
+
+A.1.2 Section 4 of RFC 2251
+
+ Portions of Section 4 of RFC 2251 detailing aspects of the information
+ model used by LDAP were incorporated in this document, including:
+
+ - Restriction of distinguished values to attributes whose descriptions
+ have no options (from Section 4.1.3);
+
+ - Data model aspects of Attribute Types (from Section 4.1.4),
+ Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8),
+ Matching Rule Identifier (from 4.1.9); and
+
+ - User schema requirements (from Section 4.1.6, 4.5.1, and 4.7).
+
+
+Clarifications to these portions include:
+
+ - Subtyping and AttributeDescriptions with options.
+
+
+
+
+
+A.1.3 Section 6 of RFC 2251
+
+
+
+
+Zeilenga LDAP Models [Page 48]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
+ where incorporated into this document.
+
+
+A.2 Changes to RFC 2252
+
+ This document incorporates Sections 4, 5 and 7 from RFC 2252.
+
+
+A.2.1 Section 4 of RFC 2252
+
+ The specification was updated to use Augmented BNF [RFC2234]. The
+ string representation of an OBJECT IDENTIFIER was tighten to
+ disallow leading zeros as described in RFC 2252 text.
+
+ The <descr> syntax was changed to disallow semicolon (U+003B)
+ characters to appear to be consistent its natural language
+ specification "descr is the syntactic representation of an object
+ descriptor, which consists of letters and digits, starting with a
+ letter." In a related change, the statement "an
+ AttributeDescription can be used as the value in a NAME part of an
+ AttributeTypeDescription" was deleted. RFC 2252 provided no
+ specification of the semantics of attribute options appearing in
+ NAME fields.
+
+ RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
+ over the <numericoid> form. However, <descr> form can be ambiguous.
+ To address this issue, the imperative was replaced with a statement
+ (in Section 1.4) that while the <descr> form is generally preferred,
+ <numericoid> should be used where an unambiguous <descr> is not
+ available. Additionally, an expanded discussion of descriptor
+ issues is discussed in Section 6.2 (Short Names).
+
+ The ABNF for a quoted string (qdstring) was updated to reflect
+ support for the escaping mechanism described in 4.3 of RFC 2252.
+
+
+A.2.2 Section 5 of RFC 2252
+
+ Definitions of operational attributes provided in Section 5 of RFC
+ 2252 where incorporated into this document.
+
+ The 'namingContexts' description was clarified. A first-level DSA
+ should publish, in addition to other values, "" indicating the root
+ of the DIT.
+
+ The 'altServer' description was clarified. It may hold any URI.
+
+
+
+
+Zeilenga LDAP Models [Page 49]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ The 'supportedExtension' description was clarified. A server need
+ only list the OBJECT IDENTIFIERs associated with the extended
+ requests of the extended operations it recognizes.
+
+ The 'supportedControl' description was clarified. A server need
+ only list the OBJECT IDENTIFIERs associated with the request
+ controls it recognizes.
+
+ Descriptions for the 'structuralObjectClass' and
+ 'governingStructureRule' operational attribute types were added.
+
+
+A.2.3 Section 7 of RFC 2252
+
+ Section 7 of RFC 2252 provides definitions of the 'subschema' and
+ 'extensibleObject' object classes. These definitions where
+ integrated into Section 4.2 and Section 4.3 of this document,
+ respectively. Section 7 of RFC 2252 also contained the object class
+ implementation requirement. This was incorporated into Section 7 of
+ this document.
+
+ The specification of 'extensibleObject' was clarified of how it
+ interacts with precluded attributes.
+
+
+A.3 Changes to RFC 2256
+
+ This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
+ 2256.
+
+ Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
+ attribute type. This was integrated into Section 2.4.1 of this
+ document. The statement "One of the values is either 'top' or
+ 'alias'" was replaced with statement that one of the values is 'top'
+ as entries belonging to 'alias' also belong to 'top'.
+
+ Section 5.2 of RFC 2256 provided the definition of the
+ 'aliasedObjectName' attribute type. This was integrated into
+ Section 2.6.2 of this document.
+
+ Section 7.1 of RFC 2256 provided the definition of the 'top' object
+ class. This was integrated into Section 2.4.1 of this document.
+
+ Section 7.2 of RFC 2256 provided the definition of the 'alias'
+ object class. This was integrated into Section 2.6.1 of this
+ document.
+
+
+
+
+
+Zeilenga LDAP Models [Page 50]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+A.4 Changes to RFC 3674
+
+ This document made no substantive change to the 'supportedFeatures'
+ technical specification provided in RFC 3674.
+
+
+
+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 at 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 Models [Page 51]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-protocol-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-protocol-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-protocol-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,3709 @@
+
+
+Internet-Draft Editor: J. Sermersheim
+Intended Category: Standard Track Novell, Inc
+Document: draft-ietf-ldapbis-protocol-32.txt Oct 2005
+Obsoletes: RFCs 2251, 2830, 3771
+
+
+ LDAP: The Protocol
+
+
+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 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/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire in February 2005.
+
+ Technical discussion of this document will take place on the IETF
+ LDAP Revision Working Group (LDAPbis) mailing list <ietf-
+ ldapbis at openldap.org>. Please send editorial comments directly to the
+ editor <jimse at novell.com>.
+
+
+Abstract
+
+ This document describes the protocol elements, along with their
+ semantics and encodings, of the Lightweight Directory Access Protocol
+ (LDAP). LDAP provides access to distributed directory services that
+ act in accordance with X.500 data and service models. These protocol
+ elements are based on those described in the X.500 Directory Access
+ Protocol (DAP).
+
+
+Table of Contents
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 1
+ Lightweight Directory Access Protocol Version 3
+
+ 1. Introduction....................................................3
+ 1.1. Relationship to Other LDAP Specifications.....................3
+ 2. Conventions.....................................................3
+ 3. Protocol Model..................................................4
+ 3.1 Operation and LDAP Message Layer Relationship..................5
+ 4. Elements of Protocol............................................5
+ 4.1. Common Elements...............................................5
+ 4.1.1. Message Envelope............................................5
+ 4.1.2. String Types................................................7
+ 4.1.3. Distinguished Name and Relative Distinguished Name..........7
+ 4.1.4. Attribute Descriptions......................................8
+ 4.1.5. Attribute Value.............................................8
+ 4.1.6. Attribute Value Assertion...................................8
+ 4.1.7. Attribute and PartialAttribute..............................9
+ 4.1.8. Matching Rule Identifier....................................9
+ 4.1.9. Result Message..............................................9
+ 4.1.10. Referral..................................................11
+ 4.1.11. Controls..................................................13
+ 4.2. Bind Operation...............................................14
+ 4.3. Unbind Operation.............................................17
+ 4.4. Unsolicited Notification.....................................17
+ 4.5. Search Operation.............................................18
+ 4.6. Modify Operation.............................................29
+ 4.7. Add Operation................................................31
+ 4.8. Delete Operation.............................................31
+ 4.9. Modify DN Operation..........................................32
+ 4.10. Compare Operation...........................................33
+ 4.11. Abandon Operation...........................................34
+ 4.12. Extended Operation..........................................35
+ 4.13. IntermediateResponse Message................................36
+ 4.14. StartTLS Operation..........................................37
+ 5. Protocol Encoding, Connection, and Transfer....................39
+ 5.1. Protocol Encoding............................................39
+ 5.2. Transmission Control Protocol (TCP)..........................40
+ 5.3. Termination of the LDAP session..............................40
+ 6. Security Considerations........................................40
+ 7. Acknowledgements...............................................42
+ 8. Normative References...........................................42
+ 9. Informative References.........................................44
+ 10. IANA Considerations...........................................44
+ 11. Editor's Address..............................................45
+ Appendix A - LDAP Result Codes....................................46
+ A.1 Non-Error Result Codes........................................46
+ A.2 Result Codes..................................................46
+ Appendix B - Complete ASN.1 Definition............................51
+ Appendix C - Changes..............................................57
+ C.1 Changes made to RFC 2251:.....................................57
+ C.2 Changes made to RFC 2830:.....................................62
+ C.3 Changes made to RFC 3771:.....................................63
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 2
+ Lightweight Directory Access Protocol Version 3
+
+1. Introduction
+
+ The Directory is "a collection of open systems cooperating to provide
+ directory services" [X.500]. A directory user, which may be a human
+ or other entity, accesses the Directory through a client (or
+ Directory User Agent (DUA)). The client, on behalf of the directory
+ user, interacts with one or more servers (or Directory System Agents
+ (DSA)). Clients interact with servers using a directory access
+ protocol.
+
+ This document details the protocol elements of the Lightweight
+ Directory Access Protocol (LDAP), along with their semantics.
+ Following the description of protocol elements, it describes the way
+ in which the protocol elements are encoded and transferred.
+
+
+1.1. Relationship to Other LDAP Specifications
+
+ This document is an integral part of the LDAP Technical Specification
+ [Roadmap] which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety.
+
+ This document, together with [Roadmap], [AuthMeth], and [Models],
+ obsoletes RFC 2251 in its entirety. Section 3.3 is obsoleted by
+ [Roadmap]. Sections 4.2.1 (portions), and 4.2.2 are obsoleted by
+ [AuthMeth]. Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5,
+ 4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph)
+ are obsoleted by [Models]. The remainder of RFC 2251 is obsoleted by
+ this document. Appendix C.1 summarizes substantive changes in the
+ remainder.
+
+ This document obsoletes RFC 2830, Sections 2 and 4. The remainder of
+ RFC 2830 is obsoleted by [AuthMeth]. Appendix C.2 summarizes
+ substantive changes to the remaining sections.
+
+ This document also obsoletes RFC 3771 in entirety.
+
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
+ to be interpreted as described in [Keyword].
+
+ 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].
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 3
+ Lightweight Directory Access Protocol Version 3
+
+ The term "transport connection" refers to the underlying transport
+ services used to carry the protocol exchange, as well as associations
+ established by these services.
+
+ The term "TLS layer" refers to TLS services used in providing
+ security services, as well as associations established by these
+ services.
+
+ The term "SASL layer" refers to SASL services used in providing
+ security services, as well as associations established by these
+ services.
+
+ The term "LDAP message layer" refers to the LDAP Message Protocol
+ Data Unit (PDU) services used in providing directory services, as
+ well as associations established by these services.
+
+ The term "LDAP session" refers to combined services (transport
+ connection, TLS layer, SASL layer, LDAP message layer) and their
+ associations.
+
+ See the table in Section 5 for an illustration of these four terms.
+
+
+3. Protocol Model
+
+ The general model adopted by this protocol is one of clients
+ performing protocol operations against servers. In this model, a
+ client transmits a protocol request describing the operation to be
+ performed to a server. The server is then responsible for performing
+ the necessary operation(s) in the Directory. Upon completion of an
+ operation, the server typically returns a response containing
+ appropriate data to the requesting client.
+
+ Protocol operations are generally independent of one another. Each
+ operation is processed as an atomic action, leaving the directory in
+ a consistent state.
+
+ Although servers are required to return responses whenever such
+ responses are defined in the protocol, there is no requirement for
+ synchronous behavior on the part of either clients or servers.
+ Requests and responses for multiple operations generally may be
+ exchanged between a client and server in any order. If required,
+ synchronous behavior may be controlled by client applications.
+
+ The core protocol operations defined in this document can be mapped
+ to a subset of the X.500 (1993) Directory Abstract Service [X.511].
+ However there is not a one-to-one mapping between LDAP operations and
+ X.500 Directory Access Protocol (DAP) operations. Server
+ implementations acting as a gateway to X.500 directories may need to
+ make multiple DAP requests to service a single LDAP request.
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 4
+ Lightweight Directory Access Protocol Version 3
+
+
+3.1. Operation and LDAP Message Layer Relationship
+
+ Protocol operations are exchanged at the LDAP message layer. When the
+ transport connection is closed, any uncompleted operations at the
+ LDAP message layer, when possible, are abandoned, and when not
+ possible, are completed without transmission of the response. Also,
+ when the transport connection is closed, the client MUST NOT assume
+ that any uncompleted update operations have succeeded or failed.
+
+
+4. Elements of Protocol
+
+ The protocol is described using Abstract Syntax Notation One
+ ([ASN.1]), and is transferred using a subset of ASN.1 Basic Encoding
+ Rules ([BER]). Section 5 specifies how the protocol elements are
+ encoded and transferred.
+
+ 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 [LDAPIANA]. Because of the implied extensibility,
+ clients and servers MUST (unless otherwise specified) ignore trailing
+ SEQUENCE components whose tags they do not recognize.
+
+ Changes to the protocol other than through the extension mechanisms
+ described here require a different version number. A client indicates
+ the version it is using as part of the BindRequest, described in
+ Section 4.2. If a client has not sent a Bind, the server MUST assume
+ the client is using version 3 or later.
+
+ Clients may attempt to determine the protocol versions a server
+ supports by reading the 'supportedLDAPVersion' attribute from the
+ root DSE (DSA-Specific Entry) [Models].
+
+
+4.1. Common Elements
+
+ This section describes the LDAPMessage envelope Protocol Data Unit
+ (PDU) format, as well as data type definitions, which are used in the
+ protocol operations.
+
+
+4.1.1. Message Envelope
+
+ For the purposes of protocol exchanges, all protocol operations are
+ encapsulated in a common envelope, the LDAPMessage, which is defined
+ as follows:
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 5
+ Lightweight Directory Access Protocol Version 3
+
+ LDAPMessage ::= SEQUENCE {
+ messageID MessageID,
+ protocolOp CHOICE {
+ bindRequest BindRequest,
+ bindResponse BindResponse,
+ unbindRequest UnbindRequest,
+ searchRequest SearchRequest,
+ searchResEntry SearchResultEntry,
+ searchResDone SearchResultDone,
+ searchResRef SearchResultReference,
+ modifyRequest ModifyRequest,
+ modifyResponse ModifyResponse,
+ addRequest AddRequest,
+ addResponse AddResponse,
+ delRequest DelRequest,
+ delResponse DelResponse,
+ modDNRequest ModifyDNRequest,
+ modDNResponse ModifyDNResponse,
+ compareRequest CompareRequest,
+ compareResponse CompareResponse,
+ abandonRequest AbandonRequest,
+ extendedReq ExtendedRequest,
+ extendedResp ExtendedResponse,
+ ...,
+ intermediateResponse IntermediateResponse },
+ controls [0] Controls OPTIONAL }
+
+ MessageID ::= INTEGER (0 .. maxInt)
+
+ maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+ The ASN.1 type Controls is defined in Section 4.1.11.
+
+ The function of the LDAPMessage is to provide an envelope containing
+ common fields required in all protocol exchanges. At this time the
+ only common fields are the messageID and the controls.
+
+ If the server receives an LDAPMessage from the client in which the
+ LDAPMessage SEQUENCE tag cannot be recognized, the messageID cannot
+ be parsed, the tag of the protocolOp is not recognized as a request,
+ or the encoding structures or lengths of data fields are found to be
+ incorrect, then the server SHOULD return the Notice of Disconnection
+ described in Section 4.4.1, with the resultCode set to protocolError,
+ and MUST immediately terminate the LDAP session as described in
+ Section 5.3.
+
+ In other cases where the client or server cannot parse an LDAP PDU,
+ it SHOULD abruptly terminate the LDAP session (Section 5.3) where
+ further communication (including providing notice) would be
+ pernicious. Otherwise, server implementations MUST return an
+ appropriate response to the request, with the resultCode set to
+ protocolError.
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 6
+ Lightweight Directory Access Protocol Version 3
+
+4.1.1.1. Message ID
+
+ All LDAPMessage envelopes encapsulating responses contain the
+ messageID value of the corresponding request LDAPMessage.
+
+ The message ID of a request MUST have a non-zero value different from
+ the messageID of any other request in progress in the same LDAP
+ session. The zero value is reserved for the unsolicited notification
+ message.
+
+ Typical clients increment a counter for each request.
+
+ A client MUST NOT send a request with the same message ID as an
+ earlier request in the same LDAP session unless it can be determined
+ that the server is no longer servicing the earlier request (e.g.
+ after the final response is received, or a subsequent Bind
+ completes). Otherwise the behavior is undefined. For this purpose,
+ note that Abandon and successfully abandoned operations do not send
+ responses.
+
+
+4.1.2. String Types
+
+ The LDAPString is a notational convenience to indicate that, although
+ strings of LDAPString type encode as ASN.1 OCTET STRING types, the
+ [ISO10646] character set (a superset of [Unicode]) is used, encoded
+ following the [UTF-8] algorithm. Note that Unicode characters U+0000
+ through U+007F are the same as ASCII 0 through 127, respectively, and
+ have the same single octet UTF-8 encoding. Other Unicode characters
+ have a multiple octet UTF-8 encoding.
+
+ LDAPString ::= OCTET STRING -- UTF-8 encoded,
+ -- [ISO10646] characters
+
+ The LDAPOID is a notational convenience to indicate that the
+ permitted value of this string is a (UTF-8 encoded) dotted-decimal
+ representation of an OBJECT IDENTIFIER. Although an LDAPOID is
+ encoded as an OCTET STRING, values are limited to the definition of
+ <numericoid> given in Section 1.4 of [Models].
+
+ LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models]
+
+ For example,
+
+ 1.3.6.1.4.1.1466.1.2.3
+
+
+4.1.3. Distinguished Name and Relative Distinguished Name
+
+ An LDAPDN is defined to be the representation of a Distinguished Name
+ (DN) after encoding according to the specification in [LDAPDN].
+
+ LDAPDN ::= LDAPString
+ -- Constrained to <distinguishedName> [LDAPDN]
+
+Sermersheim Internet-Draft - Expires April 2006 Page 7
+ Lightweight Directory Access Protocol Version 3
+
+
+ A RelativeLDAPDN is defined to be the representation of a Relative
+ Distinguished Name (RDN) after encoding according to the
+ specification in [LDAPDN].
+
+ RelativeLDAPDN ::= LDAPString
+ -- Constrained to <name-component> [LDAPDN]
+
+
+4.1.4. Attribute Descriptions
+
+ The definition and encoding rules for attribute descriptions are
+ defined in Section 2.5 of [Models]. Briefly, an attribute description
+ is an attribute type and zero or more options.
+
+ AttributeDescription ::= LDAPString
+ -- Constrained to <attributedescription>
+ -- [Models]
+
+
+4.1.5. Attribute Value
+
+ A field of type AttributeValue is an OCTET STRING containing an
+ encoded attribute value. The attribute value is encoded according to
+ the LDAP-specific encoding definition of its corresponding syntax.
+ The LDAP-specific encoding definitions for different syntaxes and
+ attribute types may be found in other documents and in particular
+ [Syntaxes].
+
+ AttributeValue ::= OCTET STRING
+
+ Note that there is no defined limit on the size of this encoding;
+ thus protocol values may include multi-megabyte attribute values
+ (e.g. photographs).
+
+ Attribute values may be defined which have arbitrary and non-
+ printable syntax. Implementations MUST NOT display nor attempt to
+ decode an attribute value if its syntax is not known. The
+ implementation may attempt to discover the subschema of the source
+ entry, and retrieve the descriptions of 'attributeTypes' from it
+ [Models].
+
+ Clients MUST only send attribute values in a request that are valid
+ according to the syntax defined for the attributes.
+
+
+4.1.6. Attribute Value Assertion
+
+ The AttributeValueAssertion (AVA) type definition is similar to the
+ one in the X.500 Directory standards. It contains an attribute
+ description and a matching rule ([Models] Section 4.1.3) assertion
+ value suitable for that type. Elements of this type are typically
+ used to assert that the value in assertionValue matches a value of an
+ attribute.
+
+Sermersheim Internet-Draft - Expires April 2006 Page 8
+ Lightweight Directory Access Protocol Version 3
+
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ assertionValue AssertionValue }
+
+ AssertionValue ::= OCTET STRING
+
+ The syntax of the AssertionValue depends on the context of the LDAP
+ operation being performed. For example, the syntax of the EQUALITY
+ matching rule for an attribute is used when performing a Compare
+ operation. Often this is the same syntax used for values of the
+ attribute type, but in some cases the assertion syntax differs from
+ the value syntax. See objectIdentiferFirstComponentMatch in
+ [Syntaxes] for an example.
+
+
+4.1.7. Attribute and PartialAttribute
+
+ Attributes and partial attributes consist of an attribute description
+ and attribute values. A PartialAttribute allows zero values, while
+ Attribute requires at least one value.
+
+ PartialAttribute ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF value AttributeValue }
+
+ Attribute ::= PartialAttribute(WITH COMPONENTS {
+ ...,
+ vals (SIZE(1..MAX))})
+
+ No two of the attribute values may be equivalent as described by
+ Section 2.3 of [Models]. The set of attribute values is unordered.
+ Implementations MUST NOT rely upon the ordering being repeatable.
+
+
+4.1.8. Matching Rule Identifier
+
+ Matching rules are defined in Section 4.1.3 of [Models]. A matching
+ rule is identified in the protocol by the printable representation of
+ either its <numericoid>, or one of its short name descriptors
+ [Models], e.g. 'caseIgnoreMatch' or '2.5.13.2'.
+
+ MatchingRuleId ::= LDAPString
+
+
+4.1.9. Result Message
+
+ The LDAPResult is the construct used in this protocol to return
+ success or failure indications from servers to clients. To various
+ requests, servers will return responses containing the elements found
+ in LDAPResult to indicate the final status of the protocol operation
+ request.
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 9
+ Lightweight Directory Access Protocol Version 3
+
+ LDAPResult ::= SEQUENCE {
+ resultCode ENUMERATED {
+ success (0),
+ operationsError (1),
+ protocolError (2),
+ timeLimitExceeded (3),
+ sizeLimitExceeded (4),
+ compareFalse (5),
+ compareTrue (6),
+ authMethodNotSupported (7),
+ strongerAuthRequired (8),
+ -- 9 reserved --
+ referral (10),
+ adminLimitExceeded (11),
+ unavailableCriticalExtension (12),
+ confidentialityRequired (13),
+ saslBindInProgress (14),
+ noSuchAttribute (16),
+ undefinedAttributeType (17),
+ inappropriateMatching (18),
+ constraintViolation (19),
+ attributeOrValueExists (20),
+ invalidAttributeSyntax (21),
+ -- 22-31 unused --
+ noSuchObject (32),
+ aliasProblem (33),
+ invalidDNSyntax (34),
+ -- 35 reserved for undefined isLeaf --
+ aliasDereferencingProblem (36),
+ -- 37-47 unused --
+ inappropriateAuthentication (48),
+ invalidCredentials (49),
+ insufficientAccessRights (50),
+ busy (51),
+ unavailable (52),
+ unwillingToPerform (53),
+ loopDetect (54),
+ -- 55-63 unused --
+ namingViolation (64),
+ objectClassViolation (65),
+ notAllowedOnNonLeaf (66),
+ notAllowedOnRDN (67),
+ entryAlreadyExists (68),
+ objectClassModsProhibited (69),
+ -- 70 reserved for CLDAP --
+ affectsMultipleDSAs (71),
+ -- 72-79 unused --
+ other (80),
+ ... },
+ matchedDN LDAPDN,
+ diagnosticMessage LDAPString,
+ referral [3] Referral OPTIONAL }
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 10
+ Lightweight Directory Access Protocol Version 3
+
+ The resultCode enumeration is extensible as defined in Section 3.6 of
+ [LDAPIANA]. The meanings of the listed result codes are given in
+ Appendix A. If a server detects multiple errors for an operation,
+ only one result code is returned. The server should return the result
+ code that best indicates the nature of the error encountered. Servers
+ may return substituted result codes to prevent unauthorized
+ disclosures.
+
+ The diagnosticMessage field of this construct may, at the server's
+ option, be used to return a string containing a textual, human-
+ readable (terminal control and page formatting characters should be
+ avoided) diagnostic message. As this diagnostic message is not
+ standardized, implementations MUST NOT rely on the values returned.
+ Diagnostic messages typically supplement the resultCode with
+ additional information. If the server chooses not to return a textual
+ diagnostic, the diagnosticMessage field MUST be empty.
+
+ For certain result codes (typically, but not restricted to
+ noSuchObject, aliasProblem, invalidDNSyntax and
+ aliasDereferencingProblem), the matchedDN field is set (subject to
+ access controls) to the name of the last entry (object or alias) used
+ in finding the target (or base) object. This will be a truncated form
+ of the provided name or, if an alias was dereferenced while
+ attempting to locate the entry, of the resulting name. Otherwise the
+ matchedDN field is empty.
+
+
+4.1.10. Referral
+
+ The referral result code indicates that the contacted server cannot
+ or will not perform the operation and that one or more other servers
+ may be able to. Reasons for this include:
+
+ - The target entry of the request is not held locally, but the
+ server has knowledge of its possible existence elsewhere.
+
+ - The operation is restricted on this server -- perhaps due to a
+ read-only copy of an entry to be modified.
+
+ The referral field is present in an LDAPResult if the resultCode is
+ set to referral, and absent with all other result codes. It contains
+ one or more references to one or more servers or services that may be
+ accessed via LDAP or other protocols. Referrals can be returned in
+ response to any operation request (except Unbind and Abandon which do
+ not have responses). At least one URI MUST be present in the
+ Referral.
+
+ During a Search operation, after the baseObject is located, and
+ entries are being evaluated, the referral is not returned. Instead,
+ continuation references, described in Section 4.5.3, are returned
+ when other servers would need to be contacted to complete the
+ operation.
+
+ Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
+
+Sermersheim Internet-Draft - Expires April 2006 Page 11
+ Lightweight Directory Access Protocol Version 3
+
+
+ URI ::= LDAPString -- limited to characters permitted in
+ -- URIs
+
+ If the client wishes to progress the operation, it contacts one of
+ the supported services found in the referral. If multiple URIs are
+ present, the client assumes that any supported URI may be used to
+ progress the operation.
+
+ Clients that follow referrals MUST ensure that they do not loop
+ between servers. They MUST NOT repeatedly contact the same server for
+ the same request with the same parameters. Some clients use a counter
+ that is incremented each time referral handling occurs for an
+ operation, and these kinds of clients MUST be able to handle at least
+ ten nested referrals while progressing the operation.
+
+ A URI for a server implementing LDAP and accessible via [TCP]/[IP]
+ (v4 or v6) is written as an LDAP URL according to [LDAPURL].
+
+ Referral values which are LDAP URLs follow these rules:
+
+ - If an alias was dereferenced, the <dn> part of the LDAP URL MUST
+ be present, with the new target object name.
+
+ - It is RECOMMENDED that the <dn> part be present to avoid
+ ambiguity.
+
+ - If the <dn> part is present, the client uses this name in its next
+ request to progress the operation, and if it is not present the
+ client uses the same name as in the original request.
+
+ - Some servers (e.g. participating in distributed indexing) may
+ provide a different filter in a URL of a referral for a Search
+ operation.
+
+ - If the <filter> part of the LDAP URL is present, the client uses
+ this filter in its next request to progress this Search, and if it
+ is not present the client uses the same filter as it used for that
+ Search.
+
+ - For Search, it is RECOMMENDED that the <scope> part be present to
+ avoid ambiguity.
+
+ - If the <scope> part is missing, the scope of the original Search
+ is used by the client to progress the operation.
+
+ - Other aspects of the new request may be the same as or different
+ from the request which generated the referral.
+
+ Other kinds of URIs may be returned. The syntax and semantics of such
+ URIs is left to future specifications. Clients may ignore URIs that
+ they do not support.
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 12
+ Lightweight Directory Access Protocol Version 3
+
+ UTF-8 encoded characters appearing in the string representation of a
+ DN, search filter, or other fields of the referral value may not be
+ legal for URIs (e.g. spaces) and MUST be escaped using the % method
+ in [URI].
+
+
+4.1.11. Controls
+
+ Controls provide a mechanism whereby the semantics and arguments of
+ existing LDAP operations may be extended. One or more controls may be
+ attached to a single LDAP message. A control only affects the
+ semantics of the message it is attached to.
+
+ Controls sent by clients are termed 'request controls' and those sent
+ by servers are termed 'response controls'.
+
+ Controls ::= SEQUENCE OF control Control
+
+ Control ::= SEQUENCE {
+ controlType LDAPOID,
+ criticality BOOLEAN DEFAULT FALSE,
+ controlValue OCTET STRING OPTIONAL }
+
+ The controlType field is the dotted-decimal representation of an
+ OBJECT IDENTIFIER which uniquely identifies the control. This
+ provides unambiguous naming of controls. Often, response control(s)
+ solicited by a request control share controlType values with the
+ request control.
+
+ The criticality field only has meaning in controls attached to
+ request messages (except UnbindRequest). For controls attached to
+ response messages and the UnbindRequest, the criticality field SHOULD
+ be FALSE, and MUST be ignored by the receiving protocol peer. A value
+ of TRUE indicates that it is unacceptable to perform the operation
+ without applying the semantics of the control. Specifically, the
+ criticality field is applied as follows:
+
+ - If the server does not recognize the control type, determines that
+ it is not appropriate for the operation, or is otherwise unwilling
+ to perform the operation with the control, and the criticality
+ field is TRUE, the server MUST NOT perform the operation, and for
+ operations that have a response message, MUST return with the
+ resultCode set to unavailableCriticalExtension.
+
+ - If the server does not recognize the control type, determines that
+ it is not appropriate for the operation, or is otherwise unwilling
+ to perform the operation with the control, and the criticality
+ field is FALSE, the server MUST ignore the control.
+
+ - Regardless of criticality, if a control is applied to an
+ operation, it is applied consistently and impartially to the
+ entire operation.
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 13
+ Lightweight Directory Access Protocol Version 3
+
+ The controlValue may contain information associated with the
+ controlType. Its format is defined by the specification of the
+ control. Implementations MUST be prepared to handle arbitrary
+ contents of the controlValue octet string, including zero bytes. It
+ is absent only if there is no value information which is associated
+ with a control of its type. When a controlValue is defined in terms
+ of ASN.1, and BER encoded according to Section 5.1, it also follows
+ the extensibility rules in Section 4.
+
+ Servers list the controlType of request controls they recognize in
+ the 'supportedControl' attribute in the root DSE (Section 5.1 of
+ [Models]).
+
+ Controls SHOULD NOT be combined unless the semantics of the
+ combination has been specified. The semantics of control
+ combinations, if specified, are generally found in the control
+ specification most recently published. When a combination of controls
+ is encountered whose semantics are invalid, not specified (or not
+ known), the message is considered to be not well-formed, thus the
+ operation fails with protocolError. Controls with a criticality of
+ FALSE may be ignored in order to arrive at a valid combination.
+ Additionally, unless order-dependent semantics are given in a
+ specification, the order of a combination of controls in the SEQUENCE
+ is ignored. Where the order is to be ignored but cannot be ignored by
+ the server, the message is considered not well-formed and the
+ operation fails with protocolError. Again, controls with a
+ criticality of FALSE may be ignored in order to arrive at a valid
+ combination.
+
+ This document does not specify any controls. Controls may be
+ specified in other documents. Documents detailing control extensions
+ are to provide for each control:
+
+ - the OBJECT IDENTIFIER assigned to the control,
+
+ - direction as to what value the sender should provide for the
+ criticality field (note: the semantics of the criticality field
+ are defined above should not be altered by the control's
+ specification),
+
+ - whether the controlValue field is present, and if so, the format
+ of its contents,
+
+ - the semantics of the control, and
+
+ - optionally, semantics regarding the combination of the control
+ with other controls.
+
+
+4.2. Bind Operation
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 14
+ Lightweight Directory Access Protocol Version 3
+
+ The function of the Bind operation is to allow authentication
+ information to be exchanged between the client and server. The Bind
+ operation should be thought of as the "authenticate" operation.
+ Operational, authentication, and security-related semantics of this
+ operation are given in [AuthMeth].
+
+ The Bind request is defined as follows:
+
+ BindRequest ::= [APPLICATION 0] SEQUENCE {
+ version INTEGER (1 .. 127),
+ name LDAPDN,
+ authentication AuthenticationChoice }
+
+ AuthenticationChoice ::= CHOICE {
+ simple [0] OCTET STRING,
+ -- 1 and 2 reserved
+ sasl [3] SaslCredentials,
+ ... }
+
+ SaslCredentials ::= SEQUENCE {
+ mechanism LDAPString,
+ credentials OCTET STRING OPTIONAL }
+
+ Fields of the BindRequest are:
+
+ - version: A version number indicating the version of the protocol
+ to be used at the LDAP message layer. This document describes
+ version 3 of the protocol. There is no version negotiation. The
+ client sets this field to the version it desires. If the server
+ does not support the specified version, it MUST respond with a
+ BindResponse where the resultCode is set to protocolError.
+
+ - name: If not empty, the name of the Directory object that the
+ client wishes to bind as. This field may take on a null value (a
+ zero length string) for the purposes of anonymous binds
+ ([AuthMeth] Section 5.1) or when using Simple Authentication and
+ Security Layer [SASL] authentication ([AuthMeth] Section 5.2).
+ Where the server attempts to locate the named object, it SHALL NOT
+ perform alias dereferencing.
+
+ - authentication: information used in authentication. This type is
+ extensible as defined in Section 3.7 of [LDAPIANA]. Servers that
+ do not support a choice supplied by a client return a BindResponse
+ with the resultCode set to authMethodNotSupported.
+
+ Textual passwords (consisting of a character sequence with a known
+ character set and encoding) transferred to the server using the
+ simple AuthenticationChoice SHALL be transferred as [UTF-8]
+ encoded [Unicode]. Prior to transfer, clients SHOULD prepare text
+ passwords as "query" strings by applying the [SASLprep] profile of
+ the [Stringprep] algorithm. Passwords consisting of other data
+ (such as random octets) MUST NOT be altered. The determination of
+ whether a password is textual is a local client matter.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 15
+ Lightweight Directory Access Protocol Version 3
+
+
+4.2.1. Processing of the Bind Request
+
+ Before processing a BindRequest, all uncompleted operations MUST
+ either complete or be abandoned. The server may either wait for the
+ uncompleted operations to complete, or abandon them. The server then
+ proceeds to authenticate the client in either a single-step, or
+ multi-step Bind process. Each step requires the server to return a
+ BindResponse to indicate the status of authentication.
+
+ After sending a BindRequest, clients MUST NOT send further LDAP PDUs
+ until receiving the BindResponse. Similarly, servers SHOULD NOT
+ process or respond to requests received while processing a
+ BindRequest.
+
+ If the client did not bind before sending a request and receives an
+ operationsError to that request, it may then send a BindRequest. If
+ this also fails or the client chooses not to bind on the existing
+ LDAP session, it may terminate the LDAP session, re-establish it and
+ begin again by first sending a BindRequest. This will aid in
+ interoperating with servers implementing other versions of LDAP.
+
+ Clients may send multiple Bind requests to change the authentication
+ and/or security associations or to complete a multi-stage Bind
+ process. Authentication from earlier binds is subsequently ignored.
+
+ For some SASL authentication mechanisms, it may be necessary for the
+ client to invoke the BindRequest multiple times ([AuthMeth] Section
+ 5.2). Clients MUST NOT invoke operations between two Bind requests
+ made as part of a multi-stage Bind.
+
+ A client may abort a SASL bind negotiation by sending a BindRequest
+ with a different value in the mechanism field of SaslCredentials, or
+ an AuthenticationChoice other than sasl.
+
+ If the client sends a BindRequest with the sasl mechanism field as an
+ empty string, the server MUST return a BindResponse with the
+ resultCode set to authMethodNotSupported. This will allow clients to
+ abort a negotiation if it wishes to try again with the same SASL
+ mechanism.
+
+
+4.2.2. Bind Response
+
+ The Bind response is defined as follows.
+
+ BindResponse ::= [APPLICATION 1] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ serverSaslCreds [7] OCTET STRING OPTIONAL }
+
+ BindResponse consists simply of an indication from the server of the
+ status of the client's request for authentication.
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 16
+ Lightweight Directory Access Protocol Version 3
+
+ A successful Bind operation is indicated by a BindResponse with a
+ resultCode set to success. Otherwise, an appropriate result code is
+ set in the BindResponse. For BindResponse, the protocolError result
+ code may be used to indicate that the version number supplied by the
+ client is unsupported.
+
+ If the client receives a BindResponse where the resultCode is set to
+ protocolError, it is to assume that the server does not support this
+ version of LDAP. While the client may be able proceed with another
+ version of this protocol (this may or may not require closing and re-
+ establishing the transport connection), how to proceed with another
+ version of this protocol is beyond the scope of this document.
+ Clients which are unable or unwilling to proceed SHOULD terminate the
+ LDAP session.
+
+ The serverSaslCreds field is used as part of a SASL-defined bind
+ mechanism to allow the client to authenticate the server to which it
+ is communicating, or to perform "challenge-response" authentication.
+ If the client bound with the simple choice, or the SASL mechanism
+ does not require the server to return information to the client, then
+ this field SHALL NOT be included in the BindResponse.
+
+
+4.3. Unbind Operation
+
+ The function of the Unbind operation is to terminate an LDAP session.
+ The Unbind operation is not the antithesis of the Bind operation as
+ the name implies. The naming of these operations are historical. The
+ Unbind operation should be thought of as the "quit" operation.
+
+ The Unbind operation is defined as follows:
+
+ UnbindRequest ::= [APPLICATION 2] NULL
+
+ The client, upon transmission of the UnbindRequest, and the server,
+ upon receipt of the UnbindRequest are to gracefully terminate the
+ LDAP session as described in Section 5.3.
+
+ Uncompleted operations are handled as specified in Section 3.1.
+
+
+4.4. Unsolicited Notification
+
+ An unsolicited notification is an LDAPMessage sent from the server to
+ the client which is not in response to any LDAPMessage received by
+ the server. It is used to signal an extraordinary condition in the
+ server or in the LDAP session between the client and the server. The
+ notification is of an advisory nature, and the server will not expect
+ any response to be returned from the client.
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 17
+ Lightweight Directory Access Protocol Version 3
+
+ The unsolicited notification is structured as an LDAPMessage in which
+ the messageID is zero and protocolOp is set to the extendedResp
+ choice using the ExtendedResponse type (See Section 4.12). The
+ responseName field of the ExtendedResponse always contains an LDAPOID
+ which is unique for this notification.
+
+ One unsolicited notification (Notice of Disconnection) is defined in
+ this document. The specification of an unsolicited notification
+ consists of:
+
+ - the OBJECT IDENTIFIER assigned to the notification (to be
+ specified in the responseName,
+
+ - the format of the contents of the responseValue (if any),
+
+ - the circumstances which will cause the notification to be sent,
+ and
+
+ - the semantics of the message.
+
+
+4.4.1. Notice of Disconnection
+
+ This notification may be used by the server to advise the client that
+ the server is about to terminate the LDAP session on its own
+ initiative. This notification is intended to assist clients in
+ distinguishing between an exceptional server condition and a
+ transient network failure. Note that this notification is not a
+ response to an Unbind requested by the client. Uncompleted operations
+ are handled as specified in Section 3.1.
+
+ The responseName is 1.3.6.1.4.1.1466.20036, the responseValue field
+ is absent, and the resultCode is used to indicate the reason for the
+ disconnection. When the strongerAuthRequired resultCode is returned
+ with this message, it indicates that the server has detected that an
+ established security association between the client and server has
+ unexpectedly failed or been compromised.
+
+ Upon transmission of the Notice of Disconnection, the server
+ gracefully terminates the LDAP session as described in Section 5.3.
+
+
+4.5. Search Operation
+
+ The Search operation is used to request a server to return, subject
+ to access controls and other restrictions, a set of entries matching
+ a complex search criterion. This can be used to read attributes from
+ a single entry, from entries immediately subordinate to a particular
+ entry, or a whole subtree of entries.
+
+
+4.5.1. Search Request
+
+ The Search request is defined as follows:
+
+Sermersheim Internet-Draft - Expires April 2006 Page 18
+ Lightweight Directory Access Protocol Version 3
+
+
+ SearchRequest ::= [APPLICATION 3] SEQUENCE {
+ baseObject LDAPDN,
+ scope ENUMERATED {
+ baseObject (0),
+ singleLevel (1),
+ wholeSubtree (2),
+ ... },
+ derefAliases ENUMERATED {
+ neverDerefAliases (0),
+ derefInSearching (1),
+ derefFindingBaseObj (2),
+ derefAlways (3) },
+ sizeLimit INTEGER (0 .. maxInt),
+ timeLimit INTEGER (0 .. maxInt),
+ typesOnly BOOLEAN,
+ filter Filter,
+ attributes AttributeSelection }
+
+ AttributeSelection ::= SEQUENCE OF selector LDAPString
+ -- The LDAPString is constrained to
+ -- <attributeSelector> in Section 4.5.1.7
+
+ Filter ::= CHOICE {
+ and [0] SET SIZE (1..MAX) OF filter Filter,
+ or [1] SET SIZE (1..MAX) OF filter Filter,
+ not [2] Filter,
+ equalityMatch [3] AttributeValueAssertion,
+ substrings [4] SubstringFilter,
+ greaterOrEqual [5] AttributeValueAssertion,
+ lessOrEqual [6] AttributeValueAssertion,
+ present [7] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] MatchingRuleAssertion,
+ ... }
+
+ SubstringFilter ::= SEQUENCE {
+ type AttributeDescription,
+ substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+ initial [0] AssertionValue, -- can occur at most once
+ any [1] AssertionValue,
+ final [2] AssertionValue } -- can occur at most once
+ }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE }
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 19
+ Lightweight Directory Access Protocol Version 3
+
+ Note that an X.500 "list"-like operation can be emulated by the
+ client requesting a singleLevel Search operation with a filter
+ checking for the presence of the 'objectClass' attribute, and that an
+ X.500 "read"-like operation can be emulated by a baseObject Search
+ operation with the same filter. A server which provides a gateway to
+ X.500 is not required to use the Read or List operations, although it
+ may choose to do so, and if it does, it must provide the same
+ semantics as the X.500 Search operation.
+
+
+4.5.1.1. SearchRequest.baseObject
+
+ The name of the base object entry (or possibly the root) relative to
+ which the Search is to be performed.
+
+
+4.5.1.2. SearchRequest.scope
+
+ Specifies the scope of the Search to be performed. The semantics (as
+ described in [X.511]) of the defined values of this field are:
+
+ baseObject: The scope is constrained to the entry named by
+ baseObject.
+
+ singleLevel: The scope is constrained to the immediate
+ subordinates of the entry named by baseObject.
+
+ wholeSubtree: the scope is constrained to the entry named by the
+ baseObject, and all its subordinates.
+
+
+4.5.1.3. SearchRequest.derefAliases
+
+ An indicator as to whether or not alias entries (as defined in
+ [Models]) are to be dereferenced during stages of the Search
+ operation.
+
+ The act of dereferencing an alias includes recursively dereferencing
+ aliases which refer to aliases.
+
+ Servers MUST detect looping while dereferencing aliases in order to
+ prevent denial of service attacks of this nature.
+
+ The semantics of the defined values of this field are:
+
+ neverDerefAliases: Do not dereference aliases in searching or in
+ locating the base object of the Search.
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 20
+ Lightweight Directory Access Protocol Version 3
+
+ derefInSearching: While searching subordinates of the base object,
+ dereference any alias within the search scope. Dereferenced
+ objects become the vertices of further search scopes where the
+ Search operation is also applied. If the search scope is
+ wholeSubtree, the Search continues in the subtree(s) of any
+ dereferenced object. If the search scope is singleLevel, the
+ search is applied to any dereferenced objects, and is not applied
+ to their subordinates. Servers SHOULD eliminate duplicate entries
+ that arise due to alias dereferencing while searching.
+
+ derefFindingBaseObj: Dereference aliases in locating the base
+ object of the Search, but not when searching subordinates of the
+ base object.
+
+ derefAlways: Dereference aliases both in searching and in locating
+ the base object of the Search.
+
+
+4.5.1.4. SearchRequest.sizeLimit
+
+ A size limit that restricts the maximum number of entries to be
+ returned as a result of the Search. A value of zero in this field
+ indicates that no client-requested size limit restrictions are in
+ effect for the Search. Servers may also enforce a maximum number of
+ entries to return.
+
+
+4.5.1.5. SearchRequest.timeLimit
+
+ A time limit that restricts the maximum time (in seconds) allowed for
+ a Search. A value of zero in this field indicates that no client-
+ requested time limit restrictions are in effect for the Search.
+ Servers may also enforce a maximum time limit for the Search.
+
+
+4.5.1.6. SearchRequest.typesOnly
+
+ An indicator as to whether Search results are to contain both
+ attribute descriptions and values, or just attribute descriptions.
+ Setting this field to TRUE causes only attribute descriptions (no
+ values) to be returned. Setting this field to FALSE causes both
+ attribute descriptions and values to be returned.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 21
+ Lightweight Directory Access Protocol Version 3
+
+4.5.1.7. SearchRequest.filter
+
+ A filter that defines the conditions that must be fulfilled in order
+ for the Search to match a given entry.
+
+ The 'and', 'or' and 'not' choices can be used to form combinations of
+ filters. At least one filter element MUST be present in an 'and' or
+ 'or' choice. The others match against individual attribute values of
+ entries in the scope of the Search. (Implementor's note: the 'not'
+ filter is an example of a tagged choice in an implicitly-tagged
+ module. In BER this is treated as if the tag was explicit.)
+
+ A server MUST evaluate filters according to the three-valued logic of
+ [X.511] (1993) Clause 7.8.1. In summary, a filter is evaluated to
+ either "TRUE", "FALSE" or "Undefined". If the filter evaluates to
+ TRUE for a particular entry, then the attributes of that entry are
+ returned as part of the Search result (subject to any applicable
+ access control restrictions). If the filter evaluates to FALSE or
+ Undefined, then the entry is ignored for the Search.
+
+ A filter of the "and" choice is TRUE if all the filters in the SET OF
+ evaluate to TRUE, FALSE if at least one filter is FALSE, and
+ otherwise Undefined. A filter of the "or" choice is FALSE if all of
+ the filters in the SET OF evaluate to FALSE, TRUE if at least one
+ filter is TRUE, and Undefined otherwise. A filter of the 'not' choice
+ is TRUE if the filter being negated is FALSE, FALSE if it is TRUE,
+ and Undefined if it is Undefined.
+
+ A filter item evaluates to Undefined when the server would not be
+ able to determine whether the assertion value matches an entry.
+ Examples include:
+
+ - An attribute description in an equalityMatch, substrings,
+ greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch
+ filter is not recognized by the server.
+
+ - The attribute type does not define the appropriate matching
+ rule.
+
+ - A MatchingRuleId in the extensibleMatch is not recognized by
+ the server or is not valid for the attribute type.
+
+ - The type of filtering requested is not implemented.
+
+ - The assertion value is invalid.
+
+ For example, if a server did not recognize the attribute type
+ shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12) and
+ (shoeSize<=12) would each evaluate to Undefined.
+
+ Servers MUST NOT return errors if attribute descriptions or matching
+ rule ids are not recognized, assertion values are invalid, or the
+ assertion syntax is not supported. More details of filter processing
+ are given in Clause 7.8 of [X.511].
+
+Sermersheim Internet-Draft - Expires April 2006 Page 22
+ Lightweight Directory Access Protocol Version 3
+
+
+
+4.5.1.7.1. SearchRequest.filter.equalityMatch
+
+ The matching rule for an equalityMatch filter is defined by the
+ EQUALITY matching rule for the attribute type or subtype. The filter
+ is TRUE when the EQUALITY rule returns TRUE as applied to the
+ attribute or subtype and the asserted value.
+
+
+4.5.1.7.2. SearchRequest.filter.substrings
+
+ There SHALL be at most one 'initial', and at most one 'final' in the
+ 'substrings' of a SubstringFilter. If 'initial' is present, it SHALL
+ be the first element of 'substrings'. If 'final' is present, it SHALL
+ be the last element of 'substrings'.
+
+ The matching rule for an AssertionValue in a substrings filter item
+ is defined by the SUBSTR matching rule for the attribute type or
+ subtype. The filter is TRUE when the SUBSTR rule returns TRUE as
+ applied to the attribute or subtype and the asserted value.
+
+ Note that the AssertionValue in a substrings filter item conforms to
+ the assertion syntax of the EQUALITY matching rule for the attribute
+ type rather than the assertion syntax of the SUBSTR matching rule for
+ the attribute type. Conceptually, the entire SubstringFilter is
+ converted into an assertion value of the substrings matching rule
+ prior to applying the rule.
+
+
+4.5.1.7.3. SearchRequest.filter.greaterOrEqual
+
+ The matching rule for a greaterOrEqual filter is defined by the
+ ORDERING matching rule for the attribute type or subtype. The filter
+ is TRUE when the ORDERING rule returns FALSE as applied to the
+ attribute or subtype and the asserted value.
+
+
+4.5.1.7.4. SearchRequest.filter.lessOrEqual
+
+ The matching rules for a lessOrEqual filter are defined by the
+ ORDERING and EQUALITY matching rules for the attribute type or
+ subtype. The filter is TRUE when either the ORDERING or EQUALITY rule
+ returns TRUE as applied to the attribute or subtype and the asserted
+ value.
+
+
+4.5.1.7.5. SearchRequest.filter.present
+
+ A present filter is TRUE when there is an attribute or subtype of the
+ specified attribute description present in an entry, FALSE when no
+ attribute or subtype of the specified attribute description is
+ present in an entry, and Undefined otherwise.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 23
+ Lightweight Directory Access Protocol Version 3
+
+
+4.5.1.7.6. SearchRequest.filter.approxMatch
+
+ An approxMatch filter is TRUE when there is a value of the attribute
+ type or subtype for which some locally-defined approximate matching
+ algorithm (e.g. spelling variations, phonetic match, etc.) returns
+ TRUE. If a value matches for equality, it also satisfies an
+ approximate match. If approximate matching is not supported for the
+ attribute, this filter item should be treated as an equalityMatch.
+
+
+4.5.1.7.7. SearchRequest.filter.extensibleMatch
+
+ The fields of the extensibleMatch filter item are evaluated as
+ follows:
+
+ - If the matchingRule field is absent, the type field MUST be
+ present, and an equality match is performed for that type.
+
+ - If the type field is absent and the matchingRule is present, the
+ matchValue is compared against all attributes in an entry which
+ support that matchingRule.
+
+ - If the type field is present and the matchingRule is present, the
+ matchValue is compared against the specified attribute type and
+ its subtypes.
+
+ - If the dnAttributes field is set to TRUE, the match is
+ additionally applied against all the AttributeValueAssertions in
+ an entry's distinguished name, and evaluates to TRUE if there is
+ at least one attribute or subtype in the distinguished name for
+ which the filter item evaluates to TRUE. The dnAttributes field is
+ present to alleviate the need for multiple versions of generic
+ matching rules (such as word matching), where one applies to
+ entries and another applies to entries and DN attributes as well.
+
+ The matchingRule used for evaluation determines the syntax for the
+ assertion value. Once the matchingRule and attribute(s) have been
+ determined, the filter item evaluates to TRUE if it matches at least
+ one attribute type or subtype in the entry, FALSE if it does not
+ match any attribute type or subtype in the entry, and Undefined if
+ the matchingRule is not recognized, the matchingRule is unsuitable
+ for use with the specified type, or the assertionValue is invalid.
+
+
+4.5.1.7. SearchRequest.attributes
+
+ A selection list of the attributes to be returned from each entry
+ which matches the search filter. Attributes which are subtypes of
+ listed attributes are implicitly included. LDAPString values of this
+ field are constrained to the following Augmented Backus-Naur Form
+ ([ABNF]):
+
+ attributeSelector = attributedescription / selectorspecial
+
+Sermersheim Internet-Draft - Expires April 2006 Page 24
+ Lightweight Directory Access Protocol Version 3
+
+
+ selectorspecial = noattrs / alluserattrs
+
+ noattrs = %x31.2E.31 ; "1.1"
+
+ alluserattrs = %x2A ; asterisk ("*")
+
+ The <attributedescription> production is defined in Section 2.5 of
+ [Models].
+
+ There are three special cases which may appear in the attributes
+ selection list:
+
+ - an empty list with no attributes,
+
+ - a list containing "*" (with zero or more attribute
+ descriptions), and
+
+ - a list containing only "1.1".
+
+ An empty list requests the return of all user attributes.
+
+ A list containing "*" requests the return of all user attributes
+ in addition to other listed (operational) attributes.
+
+ A list containing only the OID "1.1" indicates that no attributes
+ are to be returned. If "1.1" is provided with other
+ attributeSelector values, the "1.1" attributeSelector is ignored.
+ This OID was chosen because it does not (and can not) correspond
+ to any attribute in use.
+
+ Client implementors should note that even if all user attributes are
+ requested, some attributes and/or attribute values of the entry may
+ not be included in Search results due to access controls or other
+ restrictions. Furthermore, servers will not return operational
+ attributes, such as objectClasses or attributeTypes, unless they are
+ listed by name. Operational attributes are described in [Models].
+
+ Attributes are returned at most once in an entry. If an attribute
+ description is named more than once in the list, the subsequent names
+ are ignored. If an attribute description in the list is not
+ recognized, it is ignored by the server.
+
+
+4.5.2. Search Result
+
+ The results of the Search operation are returned as zero or more
+ SearchResultEntry and/or SearchResultReference messages, followed by
+ a single SearchResultDone message.
+
+ SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
+ objectName LDAPDN,
+ attributes PartialAttributeList }
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 25
+ Lightweight Directory Access Protocol Version 3
+
+ PartialAttributeList ::= SEQUENCE OF
+ partialAttribute PartialAttribute
+
+ SearchResultReference ::= [APPLICATION 19] SEQUENCE
+ SIZE (1..MAX) OF uri URI
+
+ SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+ Each SearchResultEntry represents an entry found during the Search.
+ Each SearchResultReference represents an area not yet explored during
+ the Search. The SearchResultEntry and SearchResultReference messages
+ may come in any order. Following all the SearchResultReference and
+ SearchResultEntry responses, the server returns a SearchResultDone
+ response, which contains an indication of success, or detailing any
+ errors that have occurred.
+
+ Each entry returned in a SearchResultEntry will contain all
+ appropriate attributes as specified in the attributes field of the
+ Search Request, subject to access control and other administrative
+ policy. Note that the PartialAttributeList may hold zero elements.
+ This may happen when none of the attributes of an entry were
+ requested, or could be returned. Note also that the partialAttribute
+ vals set may hold zero elements. This may happen when typesOnly is
+ requested, access controls prevent the return of values, or other
+ reasons.
+
+ Some attributes may be constructed by the server and appear in a
+ SearchResultEntry attribute list, although they are not stored
+ attributes of an entry. Clients SHOULD NOT assume that all attributes
+ can be modified, even if permitted by access control.
+
+ If the server's schema defines short names [Models] for an attribute
+ type then the server SHOULD use one of those names in attribute
+ descriptions for that attribute type (in preference to using the
+ <numericoid> [Models] format of the attribute type's object
+ identifier). The server SHOULD NOT use the short name if that name is
+ known by the server to be ambiguous, or otherwise likely to cause
+ interoperability problems.
+
+
+4.5.3. Continuation References in the Search Result
+
+ If the server was able to locate the entry referred to by the
+ baseObject but was unable or unwilling to search one or more non-
+ local e