2.1.9 LDAP Extension (ldapext)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01


Roland Hedberg <roland@catalogix.se>
M. Wahl <Mark.Wahl@innosoft.com>

Applications Area Director(s):

Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>

Applications Area Advisor:

Patrik Faltstrom <paf@cisco.com>

Mailing Lists:

General Discussion:ietf-ldapext@netscape.com
To Subscribe: ietf-ldapext-request@netscape.com
Archive: ftp://ftp.innosoft.com/ietf-ldapext/

Description of Working Group:

LDAPv3 defines an information model and an authentication model, allowing information to be protected via access control. But LDAPv3 defines no standard representation or semantic for this access control information. This work item will be to define such a standard access control model.

- Server-side sorting of search results - Paged retrieval of search results
In order to more efficiently support the assumptions of users viewing search results as a sorted, scrollable list, servers sort and provide a paged view onto search results. This work item will define the LDAPv3 message controls to allow a client to request a particular sort order, and to allow a client to retrieve search results one page at a time. The group will base its work on the following drafts:
draft-ietf-asid-ldapv3-sorting-nn.txt draft-ietf-asid-ldapv3-simple-paged-nn.txt
- Language tags
LDAPv3 carries character data in UTF-8 format, allowing the full range of international characters to be represented. This work item will be to define attribute descriptions allowing the data returned from or input to an LDAPv3 directory to be tagged identifying the language of the data, and to define an LDAP message control allowing a client to specify a preferred language. The group will base its work on the following draft:
- Dynamic directories
LDAPv3 supports static directory information that persists in its value over a relatively long period of time until it is removed. Some applications (e.g., Internet conferencing) require dynamic information that changes often and persists only as long as it is being refreshed. The deliverable from this work item will be LDAPv3 message controls and extended operations allowing the specification and refresh of dynamic directory information. The group will base its work on the following drafts:
draft-ietf-asid-ldapv3ext-04.txt draft-ietf-asid-ldap-dynatt-nn.txt
- Referral and knowledge reference maintenance
LDAPv3 is defined as an access protocol in which referrals may be returned directing a client from one directory server to others. It does not specify how this referral information is represented in the directory. The deliverable from this work item is a document defining the mechanisms by which referrals (sometimes known as knowledge references) may be maintained in a server. The group will base its work on the following draft:
- LDAP server discovery
Like most other Internet protocols, LDAPv3 is silent on the bootstrapping issue of how a client locates an LDAP server to talk to. Yet this step is necessary for any client to successfully use the directory without a priori knowledge of the directory server address it should use. The group will work in conjunction with the SVRLOC group on defining the method by which LDAP clients discover LDAP servers, based on the following document:
LDAP has an associated de facto standard C API, defined in RFC 1823. The existence of this API has proved to be of great value in spurring LDAP client development. As new features are added in LDAPv3 and the extensions discussed elsewhere in this charter, the API will need to be updated to make these new protocol features available to clients. As application development in other languages, Java in particular, occurs, the need for a standard API increases. The deliverable from this work item will be documents updating RFC 1823 for LDAPv3, documents defining API extensions to support protocol extensions, and a document defining a similar API for Java. The group will base its work on the following documents:
draft-ietf-asid-ldap-c-api-nn.txt draft-ietf-asid-ldap-java-api-nn.txt draft-ietf-asid-ldapv3-api-ext-nn.txt
LDAPv3 defines transport over TCP. In some situations, the overhead involved in setting up and tearing down TCP connections is prohibitive, requiring a lighter-weight transport. The deliverable from this work item will be a document defining transport of the LDAPv3 protocol over connectionless UDP transport. The group will expand on the work developed for LDAPv2 in RFC 1798.
- Signed directory information
In many environments clients require the ability to validiate the source and integrity of information provided by the directory. The deliverable will be a document describing an LDAP message control which allows for the retrieval of digitally signed information.
Other areas such as deployment and schema definition and review will be handled by other groups. Other areas may be added after approval by the area directors if and when they turn out to be necessary for the deployment of LDAP and feasible for the group to tackle. In particular, replication may be considered for addition to the group's charter if and when a viable approach to the problem is demonstrated.

Goals and Milestones:



Submit ID on paged retrieval of search results



Submit ID on dynamic directories



Submit ID on C LDAP API



Submit ID on sorting of search results



Submit ID on language tags



Submit ID on Java LDAP API



Meet at 40th IETF (DC)



Submit ID on paged retrieval of search results to IESG for consideration as a Proposed Standard



Submit ID on sorting of search results to IESG for consideration as a Proposed Standard



Submit ID on referrals and knowledge references to IESG for consideration as a Proposed Standard



Submit ID on signed directory information



Submit ID on recommended authentication methods



Submit ID on dynamic directories to IESG for consideration as a Proposed Standard



Submit ID on access control requirements



Submit ID on signed directory information to IESG for consideration as a Proposed Standard



Submit ID on recommended authentication methods to IESG for consideration as a Proposed Standard



Submit ID on access control

Jul 99


Submit ID on referrals and knowledge references

Jul 99


Submit ID on C LDAP API to IESG for publication as a RFC

Jul 99


Submit ID on Java LDAP API to IESG for publication as a RFC

Dec 99


Submit ID on CLDAP

Dec 99


Submit ID on access control to IESG for consideration as a Proposed Standard

Mar 00


Submit ID on CLDAP to IESG for consideration as a Proposed Standard

Mar 00


Conclude group or update WG Charter

Request For Comments:






Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services



Use of Language Codes in LDAP



An LDAP Control and Schema for Holding Operation Signatures



LDAP Control Extension for Simple Paged Results Manipulation



Access Control Requirements for LDAP



Authentication Methods for LDAP



Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security



LDAP Control Extension for Server Side Sorting of Search Results

Current Meeting Report

LDAPEXT: LDAP Extensions Working Group
Minutes recorded by Mark Wahl <Mark.Wahl@sun.com>

- preliminaries
- extensions
- server discovery
- access control
- subentries
- schema updates


Agenda discussion: where should the interaction of replication and Access control be discussed? John Strassner said: Replication issues for acls are part of the scope of the acl document.

Draft status:

cldap: there is a new draft -01.

C API: no progress since last meeting.

duplicate entries: last call will be done after meeting.

java API: in WG last call.

matched valued: last call will be done after meeting.

referrals: last call on Kurt's document will be done after meeting. no progress for other referral types.

server discovery: would like to last call the locate document after the meeting. The taxonomy document is waiting on locate.

subentries: there is a new draft -07.

X.509 SASL mechanism: no WG activity, would like to push out of WG and make an individual work item.

VLV: pending on the resolution of result codes, but otherwise done.

There was a brief charter discussion: What is LDAPEXT heading for?? Many possible future work items were discussed at the last meeting, but other than those around schema update (to be discussed at the end of this meeting), there was not a sign of significant interest from many different people in working on them, only a few people seemed interested in these work items.

Charter and futures discussion taken to the mailing list.

Extension guide

Topics discussed: result codes, meaning of multiple controls, border between defining new extensions and controls, extension to the ASN.1.

Result codes: How to extend result codes? A result code for controls?

Kurt Zeilenga proposed having an IANA registry and a review process. He will write a BCP for last calling in both LDAPBIS and LDAPEXT.

Bob Morgan suggested also a directorate to review other uses of LDAP. Those discussions would then not need to occur on the working group mailing lists. Ed Reed emphasised the need for review, to differentiate the use of extensions to the directory for using the directory, versus using LDAP as an arbitrary RPC. Kurt Zeilenga recommended that this group would not itself have enforcement power to restrict what implementors would do, but could prevent conflicts through the use of a registry of known extensions.

Multiple controls: what happens when this interaction is not defined? There could be a mismatch between this and the extensions handling behavior in X.500 and in PKIX for certificate extensions. Kurt Zeilenga recommended not specifying the behavior for LDAP in order to avoid constraining controls: if clients want particular semantics they should mark the controls as critical. As there has been discussion for existing controls and their interaction, Mark Wahl added that when an existing control RFC goes to Draft Standard status, then textual clarifications could be added to resolve ambiguities.

When to define an extension versus when to define a control: should be in the extensions guide.

How much to change in the ASN.1 when extending? Kurt Zeilenga proposed that the type or scope of an extension could change the PDU if the peer advertised support for it; others that the extension should not contradict the underlying specification.

Server discovery through DNS (Bob Morgan)

The document contains an algorithm to map some distinguished names to domain names. Tim Polk, co-chair of PKIX, said he would like to use this general approach to locate directory servers, but the locate draft is too rigid. PKI today has no global directory infrastructure, so a PKI user needs to find information from directory servers in other organizations. One solution is to embed information into certificates and CRLs, such as the name of the repository, but this is not elegant. The PKI repository locator service uses DNS to find it: it will become an experimental RFC as it covers any possible protocol. There is a need to find directories, and for that they need to find out what the domain name is of the end-cert organization.

PKIX's specifications are agnostic about names: DN might be composed of any attributes. Early adopters of PKI have used X.520 attributes: their certificates have had names rooted in C=US etc. Tim Polk proposed that locate would be more useful with this change: process all RDN components, ignoring those which are not domain components. While future deployments might move to DC components entirely, this change would provide a migration strategy.

Some of the issues discussed:

- The locate draft is based on RFC 2247, which is a bidirectional mapping. Would it be necessary to update 2247 as well? (Mark Wahl)

- This change may also imply a change in multivalued attributes processing. (Bob Morgan)

- End users could add DC components 'below' their name, this might have a security consideration. (Kurt Zeilenga)

- Also need to consider internationalized domain components. (Kurt Zeilenga)

- Is the specification the only way to map from distinguished names to domain names? If this specification were to be a Proposed Standard, could there be others, for example to consider the problem where there are domain components elsewhere in the DN? (Paul Leach)

- There is a different approach from ITU-T/ISO X.500 for more general mapping of distinguished names, based on a new DNS resource record. Skip Slone will publish an internet draft. (Skip Slone)

- A variant which allows for any domain components (not just those on the right) to be used only if the certificate can be validated, by 'canonicalizing' the DN. (Paul Leach)

- Domain entries below organizations may not be supported by the current DIT containment rules in X.500. (Ed Reed)

- When using TLS, there are rules for matching names in server certificates. (Bob Morgan)

The document authors will get input and review possible changes. If there are changes and a new internet draft, it might need to go back through WG last call.


- application defined permission and extensibility
- extensible operation permission
- replication requirements

Ellen Stokes said that it was resolved at a prior meeting that application defined permission would be out of scope. Kurt Zeilenga added that a new attribute type could be defined.

As John Strassner, co-chair of LDUP, requested that replication requirements of a document should be addressed in the working group where the document is authored, Rick Huber will incorporate replication requirements into the access control drafts. This will be completed by the next meeting, with a draft in June suitable for last call.

Subentry-07 (Ed Reed)

Changes in subentry -07:
- applied changes requested at last IETF,
- removed inheritance propigation discussion to draft-reed-,
- removed search filter mechanism, to avoid the complexity of search filters, use control only or base object search.

Kurt Zeilenga added that he would like to allow for any scope search to match subentries if the base of the search is a subentry.

Ed Reed will separate inheritableLDAPSubentry to a different document, and issue revision -08.

LDAP Schema update procedures (Tim Hahn)

Follow on from a Bar BOF at San Diego.

Topic areas of interest:

- procedures for merging and updating schema in server.
- extensions to attributeTypes and objectClasses BNF for flags, such as uniqueness, referential integrity etc.
- determine allowable changes to existing schema entries, e.g. changing matching rules of an attribute might do harm (cause inconsistency in the DIT).
- define procedures for partitioning schema.
- Define how to ensure that unique attribute and object class names are used.
- Allow clients to discover attribute type options e.g. ;binary.

There is some interest in this work area. There was discussion of whether this belongs in LDAPEXT, or might be a new follow-on working group.

End of Meeting


None received.