2.1.8 LDAP Extension (ldapext)

NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98


Tim Howes <howes@netscape.com>
M. Wahl <M.Wahl@critical-angle.com>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>

Applications Area Advisor:

Keith Moore <moore@cs.utk.edu>

Mailing Lists:

General Discussion:ietf-ldapext@netscape.com
To Subscribe: ietf-ldapext-request@netscape.com

Description of Working Group:

LDAP version 3 has laid a solid foundation for directory access on the Internet. More work is needed to provide a full Internet directory service. The LDAP Extension working group will define and standardize extensions to the LDAP version 3 protocol and extensions to the use of LDAP on the Internet. The group will also extend and standardize the existing de facto application program interface to LDAP. The planned work items include the following areas, many of which have been previously discussed for some time in the ASID working group:

- Authentication

LDAPv3 contains an extensible SASL-based authentication framework. This work item will be to document the forms of client authorization provided by specific SASL mechanisms.

- Access control

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-00.txt draft-ietf-asid-ldapv3-simple-paged-01.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-00.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-00.txt draft-ietf-asid-ldap-java-api-00.txt draft-ietf-asid-ldapv3-api-ext-00.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:

Nov 97


Submit ID on paged retrieval of search results

Nov 97


Submit ID on dynamic directories

Nov 97


Submit ID on referrals and knowledge references

Nov 97


Submit ID on sorting of search results

Nov 97


Submit ID on language tags

Nov 97


Submit ID on Java LDAP API

Nov 97


Submit ID on C LDAP API

Dec 97


Meet at 40th IETF (DC)

Dec 97


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

Dec 97


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

Dec 97


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

Dec 97


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

Dec 97


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

Dec 97


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

Dec 97


Submit ID on access control requirements

Dec 97


Submit ID on signed directory information

Dec 97


Submit ID on recommended authentication methods

Mar 98


Submit ID on access control

Mar 98


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

Mar 98


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

Mar 98


Submit ID on CLDAP

Jul 98


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

Jul 98


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

Aug 98


Conclude group or update WG Charter


No Request For Comments

Current Meeting Report

Minutes for LDAPEXT Meeting at Chicago IETF
Reported by Mark Wahl

1. Recommended Authentication Methods for LDAP draft

There is a requirement for interoperability between implementations that perform
updates to the directory. The IESG had added a note to the LDAPv3 RFCs stating
this interoperability would potentially only be possible with exchange of passwords in
the clear. Therefore the recommended authentication methods draft and related "Start
TLS" draft addressed defining an authentication method better than passwords in the
clear that would be mandatory for LDAP implementations to support.

It was noted that the mandatory to implement algorithm is not mandatory for any
organization to deploy.

The Start TLS document passed last call with minor edits.

The authentication methods draft did not successfully complete last call, primarily as
there was significant discussion on the choice of authentication mechanism.

There were four options discussed at the meeting:

The area director Patrik Falstrom advised the WG that other documents produced by
the WG that do not depend on this can go forward to IETF last call, so long as
progress is being made on the mandatory-to-implement authentication method issued.

This discussion focussed on:
- was CRAM-MD5 viable?
- is TLS acceptable to client vendors? Many vendors of clients present indicated
they planned to implement TLS/SSL, although there were comments that it
would not be acceptable to builders of embedded LDAP clients for small devices,
and that it was overkill to encrypt an entire session just for a single password
exchange. Was there a need for a single mandatory to implement for all LDAP
implementations, or could there be different profiles for different application
- Would a situation in which there were a choice of mechanisms, of which a server
must implement ALL but a client AT LEAST ONE, be acceptable?

A pre-meeting on applications area mandatory to implement mechanisms had resulted
in a plan by Chris Newman and Paul Leach to work on a new protected password
mechanism that would be acceptable for use in many application area protocols and
replace CRAM-MD5 and RFC 2069.
The Start TLS draft will have its dependencies on the recommend authentication
methods draft removed, and will progress. Should a new acceptable mechanism become
available in a few weeks, the recommended authentication methods draft will have
CRAM-MD5 replaced by that mechanism.

WG ACTION: Start TLS to IETF last call

2. Access Control

The WG chairs had sent a poll on the mailing list on how progress should be made on
this topic.

The results had been:
- Should the WG work on this? Yes
- Was the requirements draft generally accepted? Yes
- Was the ACL Model draft generally accepted? No
- Should X.500 ACLs be investigated further as the basis for LDAP? Yes
- Should just a framework, or a framework and model be defined? both

A framework draft, based on that of the X.500, will be written and sent to the list
before the next meeting.

Bob Blakely discussed a new approach for building an access control model: define
new protocol operations for "grant", "deny" and "get effective" rights. These could be
specified with least common denominator subjects and rights information, and allow
clients to modify and test access controls without needing to be aware of the encodings
of access control inside the server. A quick poll showed a lot of interest in having
minimum semantics, however the majority of the discussion on this approach was
centered on the issue of how this information could be replicated. In particular, did
there need to be a transfer syntax, and if so, how this would be different from the
vendor's own representation format.

WG ACTION: the requirements draft to go to WG last call

3. Language Tags

The Use of Language Tags in LDAP draft had completed working group last call. It
is not dependent on authentication methods.

WG ACTION: send to IESG for IETF last call

4. Sorting, Paging and Scrolling

There was one question asked on virtual list views: there didn't seem to be a cookie
exchange in the protocol, which Mark Smith said was by design.

WG ACTION: The Virtual List Views and Server-side Sorting drafts will be sent to
working group last call to become standards track.

WG ACTION: The simple paged draft will be published as Informational, not as
standards track.

5. Referrals

The referrals document had gone through last call and significant comments on it were
received. This will be split into two separate drafts: one on the hierarchical (superior/
subordinate refererence) use of referrals, and the other on a CIP-like mesh on referrals.
The two drafts will progress independently, as the hierarchical part appears to have
consensus to move to standards track, while the mesh part is still under discussion.

6. SASL mechanism for X.511 authentication

There was not much interest seen at the meeting by vendors to implement or standardize
this draft. It will go informational.

WG ACTION: send to RFC editor as informational

7. Transactions

The draft is going to be revised.

8. Persistent or Triggered Search

The two drafts were to be merged into a single draft, and this has not yet occured. At
least another revision will be needed.

There were comments that the document does not caution safe use on the Internet and
there had been little operational experience, so may not yet be suitable for being a
Proposed Standard. The document may also need to refine or state its domain of
applicablilty as a small number of clients.

9. Signed Operations

The Signed Operations draft was not discussed as the authors were not present. Some
comments were that it needed better clarification of purpose and a less generic title.


The C API draft is nearly ready for last call after one more revision.

The Java draft needs to be revised, and there were at least one set of comments on it.


None received.

Attendees List

None received.