2.1.7 LDAP Extension (ldapext)

NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 11-Mar-98


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

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Harald Alvestrand <Harald.Alvestrand@maxware.no>

Applications Area Advisor:

Harald Alvestrand <Harald.Alvestrand@maxware.no>

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 validate 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 of the LDAP Extension (ldapext) Working Group

ldapext met in three sessions on April 1st, 1998.

First Session

1. Agenda Review

Several additional topics were added to the agenda: Start TLS and recommended authentication methods, security parameters for signed operations, transactions, schema constraints and referrals.

A request to discuss NIS integration was referred to the LSD working group.

2. Status Update

The draft describing extensions for dynamic entries has completed WG last call and has been sent to Harald Alvestrand.

ACTION (Mark Wahl and Tim Howes): send draft on caching, which has completed last call, to Harald.

ACTION (Mark Wahl): revise draft on language tags and send to Harald.

Consensus was not reached on the simple paged draft as a standards track document. The WG chairs and area directors will discuss with the authors of that document whether it should be published as an informational document.

There were significant comments on the referral draft during its last call period.

ACTION (Mark Wahl and Tim Howes): revise the referral draft and issue last call again.

However, the area directors will not publish these extension documents until the recommended authentication methods document has been published.

3. Start TLS and Recommended Authentication Methods

3.1. Preventing man-in-the-middle attacks

An issue was discussed on the mailing list regarding whether client implementations are required to check that the server to whom they have established a TLS connection is identified as the subject of the server's certificate. This depends on the representation of the server's DNS name in the certificate. It was suggested that there needs to be either text in the security considerations section, or the client behavior must be documented. The client behavior text would depend on the TLS WG, since it affects all application protocols using TLS.

ACTION (Jeff Hodges): send suggested text to the security area for review, then submit revised Start TLS draft.

3.2. Format of authorization identifiers

The second issue was whether authorization ids used in the SASL credentials field must be Distinguished Names or not. A Distinguished Name is syntactically unambiguous, however some simple clients may not know their own Distinguished Name and would want to use a more basic username. The SASL RFC requires that the protocol, in this case LDAPv3, define precisely the form of this ID, however this has not been done in RFC 2251, and so the issue has arisen in the recommended authentication methods document.

It was noted by Paul Leach that the binding between the authorization id and the user is not necessarily authenticated. Also it was noted that if a DN is not used, then the mapping of a username to a DN needs to be algorithmically represented so that it can be replicated between servers.

A resolution was reached in the third session, following a BOF between Mark Wahl, Bob Morgan, John Meyers.

ACTION (Mark Wahl): produce new authentication methods draft, then go to last call.

4. Sorting

Chris Weider described the changes discussed on the mailing list. These were to clarify the handling of entries that lack the attributes being used for sorting, and to note that sorting is not done across servers where there are referrals.

ACTION (Chris Weider): reissue draft with these changes, then the WG will go to last call.

5. Access Control Requirements

Ellen Stokes summarized the open issues with the document. These are primarily whether there could be explicit denials, and nested groups. The draft currently suggests both should be not-recommended.

5.1. Nested Groups

Richard Huber noted that nesting is useful to prevent a proliferation of groups. However, with nesting there can be side effects not known to the administrator of one group if a group under another administrator's control is modified. Jeff Hodges suggested it was the responsibility of the deployers to ensure that consistency was maintained, rather than the responsibility of the specification to prevent it from occurring.

5.2. Explicit Denials

Paul Leach raised the issue from the WEBDAV working group, that it is hard to disallow access if there are multiple access protocols as there is no common ACL format.

Richard Huber also suggested that with inherited access control it is more necessary to have negative rights.

Tim Howes and Bob Blakely polled the meeting and determined there was rough consensus on this topic.

ACTION (Bob Blakely) revise the document to allow explicit denials.

6. Access Control Model

Deborah Byrne described their proposed access control model, for which a draft had recently been sent to the list. Each access control subject has security attributes that describe the permitted actions. Attributes are grouped into classes by sensitivity. Inheritance would be used to eliminate the need to store access control information with every entry.

7. LDAP Signed Operations

Pat Richard listed his planned changes to the LDAP Signed Operations document. This would be to include a reference to PKCS #7 for the definition of the LDAP signature, and make the signature structure more extensible. There was also interest in merging with the draft from Vesna Hassler.

ACTION (Pat Richard): produce updated draft.

8. Persistent and Triggered Search

There are still two proposals for client notification of search changes, however the proposals have slightly different properties and each is suited for particular ranges of applications.

Russell Weiser pointed out that the documents require more work in the security considerations sections, and Harald Alvestrand reminded the authors to be sure to discuss the implications on scaling as the number of users and the number of updates increases.

ACTION (Mark Wahl and Mark Smith): revise both documents and reissue.

9. Scrolling

David Boreham described the current state of the virtual list view draft. The document currently requires that sorting also be used simultaneously, and there have been some comments on this as the simple paging draft did not require sorting.

ACTION (David Boreham): revise draft and reissue.

10. C API

Mark Smith listed the minor issues which still need to be done: changes to data type definitions, cleanup of the language regarding when information should be freed, and integrate comments from Mark Wahl relating to the functions added in the latest revision.

There is a new function for determining the version of the protocol supported by the C API, and Mark Wahl suggested that this should also be extended to support the detection of API capabilities as there is a proliferation of extension API documents.

ACTION (Mark Smith): revise draft and reissue.

11. Transactions

A document was recently published on adding transaction operations to LDAPv3.

There are still some open issues, such as time limits on transactions, whether nested transactions and operations across referrals are supported, and the interactions with other protocol extensions.

There was no consensus on whether this should be added to the charter.

End of First Session

Second Session

12. Access Control

12.1 Prescriptive ACLs

Helmut Volpers asked about the capability of defining prescriptive ACI for covering a whole subtree of entries. Bob Blakely suggested this would be done through inheritance, however inheritance is not yet defined for LDAP.

It may be desirable to allow Prescriptive ACIs to cross server naming context boundaries, therefore the mechanism would need to be defined in LDAP how changes to one server are reflected to subordinate servers.

12.2. Relationship to X.500

There were questions why the access control format and model defined in X.500(1993) was not used. There was interest in investigating a subset of the X.500 model for use in LDAP.

ACTION (Ellen Stokes): document an analysis of the relationship to X.500(93) access control

12.3. Nested Groups and Explicit Denial

Since these topics were discussed earlier, there was a meta-discussion on whether there should be optional or extensible elements in the access control specification. If so, how are these handled when there is replication?

12.4. Subject Expressability

It is desirable to be able to express in the model certain subjects, such as "self" or "everyone".

12.5. Default ACL Policy

The proposal had appeared to describe the default access control policy as granting read access to everyone, and Ed Reed and others had suggested that the default should be changed to granting no access. In their proposal, the default access control policy for attributes could be changed by the administrator.

12.6. Multiple ACL Formats

Two related topics were discussed: whether there should be a mandatory to implement access control mechanism for LDAP, and more generally, whether access control in IETF application area protocols should be defined in terms of policy on the objects accessed or policy on the protocol.

ACTION (Tim Howes): ask for input from the security Area Director.

End of Session

Third Session

13. Authorization ID Format

The third session presented a proposed resolution to the representation of authorization identifiers in SASL credentials. In the revised document, the authorization id should be a choice of "dn:" followed by a DN, "u:" for user followed by a UTF-8 encoded username, or a zero length string.

There may be more discussion on the list on the related topics of replicating mappings for usernames to DNs, and on server proxying.

End of Third Session

Mark Wahl, Directory Product Architect
Innosoft International Inc. / Critical Angle Inc.


None Received

Attendees List

go to list