2.1.13 LDAP Extension (ldapext)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 06-Nov-97

Chair(s):

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.T.Alvestrand@uninett.no>

Applications Area Advisor:

Harald Alvestrand <Harald.T.Alvestrand@uninett.no>

Mailing Lists:

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

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

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:

draft-ietf-asid-ldapv3-lang-02.txt

- 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:

draft-ietf-asid-ldapv3-referral-00.txt

- 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:

draft-ietf-svrloc-discovery-01.txt

- LDAP APIs

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

- CLDAP

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

Internet-Drafts:

No Request For Comments

Current Meeting Report

Minutes of the LDAP Extension (LDAPEXT) WG

Action Summary

I. Agenda Review

Partition management and transactions were proposed for discussion as potential additions to the charter.

Discussion of recommended authentication methods and access control requirements were moved up in the agenda, in case the group ran out of time.

C/Java APIs and Dynamic Attributes drafts were not discussed at the meeting.

II. Charter Review

2.1. Caching

As there was a draft already near completion, the use of a ttl attribute for caching was agreed to be added to the charter. See item 5 below for more about this caching draft.

ACTION (chairs): add "caching" to charter.

2.2. Persistent or triggered search

There were two proposals made for a design by which an LDAP server could, if requested, asynchronously notify a connected client that entries had been added to the directory. These proposals are documented in:

draft-smith-ldap-psearch-00 (Mark Smith et al)
draft-wahl-ldapv3-trigger-00 (Mark Wahl)

The group discussed whether:

Consensus was reached that this topic should be added to the charter of the working group.

ACTION (chairs): add "persistent or triggered search" to charter.

Discussion of the details of the two proposals should be done on the working group mailing list.

2.3. Normalized match

Jeff Hodges proposed a need for having new matching rules for attributes whose values contain human-readable strings, in particular names. These rules would allow the server to better support comparison of names containing non-ASCII characters.

A BOF for a new working group "lessor" was held at the IETF, to develop a framework for registering matching rules to be used in application servers which support filtering on string-based attributes. These would include LDAP servers, as well as IMAP and ACAP servers.

At this meeting, consensus of the group was that this item was not to be added to the charter.

2.4. Partition management

Russel Weiser proposed the addition of LDAP server partition management to the working group charter. Partition management would include topics such as the moving of whole subtrees of entries between servers, support for backlinks, and the impacts on access control of administrative areas which cross server boundaries.

At this meeting, consensus of the group was that this item was not to be added to the charter.

2.5. Transactions

Sanjay Jain proposed the addition of Transactions to the working group charter. Ellen Stokes said that she and others had been identifying requirements for transactions in LDAP, and would produce a draft for the group to review.

ACTION (Ellen Stokes): produce draft on transaction requirements.

3. Recommended authentication methods

The core LDAP protocol document, RFC 2251, includes an IESG note that implementations may not interoperate with a secure authentication mechanism as there is no mandatory-to-implement security mechanism provided in the document.

Mark Wahl described the planned changes to the document draft-ietf-ldapext-authmeth:

1 Fix error in description of CRAM-MD5 and make it a MANDATORY SASL mechanism for implementations.

2 Improve description of TLS certificate-based authentication and make EXTERNAL a RECOMMENDED SASL mechanism.

3 Add description of simple (password based) inside of a TLS encrypted connection and make it a RECOMMENDED method.

With the publication of an RFC with these statements, it is expected the IESG restriction on the LDAP protocol could be removed.

This draft references draft-ietf-asid-ldapv3-tls-02 draft for the definition of how TLS is used in LDAP. That draft can now move forward as TLS has been approved by the IESG.

ACTION (Mark Wahl): send updated draft on authentication methods to the list.

4. Dynamic Entries

Yoram Yaacovi reviewed the recent comments seen on the mailing list regarding draft-ietf-asid-ldapv3-dynamic-07, which has completed working group last call. These were:

A mapping of the extended operation onto a DAP Modify request could be documented.

Yoram also noted that he would in the future produce a draft on dynamic non-leaf objects.

The consensus of the working group meeting was that the document should be sent to the IESG to become a Proposed Standard RFC.

ACTION (chairs): initiate IETF last call on this document.

5. Caching

The consensus of the working group meeting was that the document draft-ietf-asid-ldap-cache-01, which had completed working group last call, should be sent to the IESG to become a Proposed Standard RFC.

ACTION (chairs): initiate IETF last call on this document.

6. Sorting

As the author was not present at the meeting, discussion of the sorting document was deferred to the mailing list.

7. Referrals and knowledge maintenance

Mark Wahl and Tim Howes summarized the document draft-ietf-asid-ldapv3-referral-00 on representing LDAP knowledge in the directory. There was a minor error that would need to be corrected in a revised draft before it could be sent to the IESG. There had also been a request from the mailing list to document the relationship between the LDAP referral knowledge model and the X.500 knowledge model, and a request at the meeting to be able to indicate whether a referral is to a master or shadow copy of data.

The consensus of the working group meeting was than an updated draft should become a standards-track RFC.

ACTION (Tim Howes): produce updated draft,
ACTION (chairs): initiate working group last call.

8. Use of language tags

Mark Wahl summarized the proposed changes to the document draft-ietf-asid-ldapv3-lang-02, in particular the removal of the preferred language indication control.

The consensus of the working group meeting was that an updated draft should become a standards-track RFC.

ACTION (Mark Wahl): produce updated draft,
ACTION (chairs): initiate working group last call.

9. Start TLS

Jeff Hodges discussed the proposed changes to the document draft-ietf-asid-ldapv3-tls-02.

The consensus of the working group meeting was than an updated draft should become a standards-track RFC.

ACTION (Jeff Hodges): produce updated draft,
ACTION (chairs): initiate working group last call.

10. Signed information control

Pat Richard made a presentation of the proposal for a signed information control, which would allow an LDAP server to return a digital signature associated with an LDAP result. A document describing this proposal will be produced and circulated to the list.

ACTION (Pat Richard): send draft to the list.

11. Paging and scrolling

There are two documents on search result paging and scrolling. Draft-ietf-asid-ldapv3-simplepaged-01 allows the client to request that the server return search results in pages, but does not allow the client to scroll forward and backward in the result set. Draft-ietf-ldapext-ldapv3-vlv-00 allows the client to move to arbitrary locations in the result, but requires that the server sort results. Further discussion of these documents will occur on the list.

12. Access control requirements

Ellen Stokes said that she had received several comments on the document draft-stokes-ldapext-acl-reqts-00.

ACTION (Ellen Stokes): send an updated draft to the list.

The next meeting will be held at the IETF in March 1998.

Slides

None Received

Attendees List

go to list

Previous PageNext Page