2.1.9 LDAP Extension (ldapext)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98

Chair(s):

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:

Patrik Faltstrom <paf@swip.net>

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

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:

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

Internet-Drafts:

No Request For Comments

Current Meeting Report

IETF LDAPEXT Meeting Minutes
December 9, 1998

Reported by Mark Wahl

1. Introduction

Two topics was added to the draft agenda that had been sent to the list earlier in the week: families of entries and X.500(2000) update.

Discussion on root DSE attributees was referred to the list.

2. Mark Wahl briefly summarized the drafts that had completed last call.

The mandatory-to-implement authentication (MTI) drafts, draft-ietf-ldapext-authmeth-03.txt, draft-ietf-ldapext-ldapv3-tls-04.txt and draft-leach-digest-sasl-01.txt had gone through last call and would be sent to the Area Directors to be progresed as Proposed Standard RFCs. This resolved the issue of a lack of MTI non-cleartext password authentication mechanism that was present when the LDAPv3 drafts were completed.

The drafts on language tags, dynamic entries and simple paging had already completed working group last call, and had been waiting for the MTI authentication issue to be resolved.

At the time of the meeting, the following drafts were in last call: draft-ietf-ldapext-vlv-02.txt, draft-ief-ldapext-sorting-01.txt, draft-ietf-ldapext-x509-sasl-00.txt, draft-ietf-ldapext-c-api-01.txt and draft-itef-ldapext-acl-reqts-01.txt.

3. Ellen Stokes gave an updated proposal for an Access Control model.

This proposal is baesd on defining a standard way of manipulating access control, without requiring a standard access control information transfer encoding between the managing client and server.

Access control policy information would conceptually be stored in the directory, but clients would use controls and extended operations to set access controls, get effective access rights and list subject's rights.

This would not forbid there being one (or more) possible formats in which the data would actually be stored in servers, but would allow clients to interoperate to a degree with servers whose access control format was unknown to them.

A straw poll showed there was interest by implementors in this approach.

Discussion focused on two main topics, the need for a common representation format, and the form of subject identity.

A common representation of access control information is needed for replication, either through the replication protocol being developed in LDUP, or informally in LDIF files, which do not exchange operations, but the entries themselves.

The subject identity in the proposal is in the form of a DN. Security protocols being done in CAT and other working groups use a more generic ( mechanism + mechanism-specific identity object ) format. Another approach would be to have clients ask the server to map their authentication mechanism-specific identity into a DN, which the client could then use in access control operations.

4. Mark Smith reviewed the LDAP C API draft status.

LDAP C API Slides Presented at IETF 43 in Orlando by Mark Smith <mcs@netscape.com>

Slide 1 of 3 (overview):

- Draft has been around for a long time and is widely deployed.
- Tradeoff between compatibility and perfection of API.
- Pressure from both sides.
- Current draft passes the "It is useful and it works for many people" test with flying colors.

Slide 2 of 3 (open issues that are currently listed in the draft and proposed resolution):

- 23.1 Threading ==> extension doc.
- 23.2 TLS ==> extension doc.
- 23.3 Referrals client control ==> add now?
- 23.4 IPv6 compatibility ==> address now
- 23.5 SASL API std? ==> later
- 23.6 Non-UTF8 charsets ==> note and put in extension doc.
- 23.7 LDAP session options ==> ?
- 23.8 Rebind callback ==> add now
- 23.9 API extension mechanism ==> nearly done

Slide 3 of 3 (other open issues that were raised on the mailing list and proposed resolution):

- A. Use of 'const' in LDAP ==> add as a SHOULD
- B. LDAPv2 compatibility ==> ?
- C. Use of 'int' vs. LDAPINT32 ==> ?
- D. 'ldap.h' header file requirements ==> add now
- E. Finer grained client side timelimits in ldap_set_option() ==> extension
- F. Document incompatibilities with RFC 1823 ==> later
- G. BER bug fixes and clarifications ==> address now
- H. Improve non-blocking I/O and select/poll support (for multiprotocol applications) ==> extension
- I. Opaqueness of structs; use of arrays ==> the right tradeoff has been made; do nothing.

5. Signed Operations

There were few issues noted with the signed operations document, and there was rough concensus that EXPERIMENTAL was the best status for this document at present. One concern was that the title did not quite reflect the contents of this document.

6. Referrals

The referrals draft is being split into two parts: one part with the return of referrals by servers holding hierarchically-arranged naming contexts, the second with the return of referrals holding mesh or index information.

7. Jim Sermersheim presented his draft on the return of Duplicate Entries in search results. This was intended for generating a sorted listing when the sort key attributes are multi-valued, and for handling group entries with many members.

There was also interest in having range queries on attribute values, so that a client could retrieve some but not all values. This would help with managing an entry with a attribute containing a large number of values, but not with the sorting problem.

There was concensus that this would should progress on the standards track.

8. David Chadwick requested the group's input on the issue of representing Compound Attributes, which collect a set of related attributes in a package that is distinct from another set of attributes associated with an entry. (An example might be a person's sets of work and home contact details.)

The X.500 standards community was considering two approaches:

A preference was expressed for the family of entries approach. This would allow existing DIT schema and access control rules to govern these compound attributes more easily.

There was concensus to investigate this issue for LDAP directories as part of the LDAPEXT working group.

Also, Mark Wahl took an action to document the use of attribute option labels as another simple approach of building compound attributes.

9. David Chadwick presented the other new services being added into the X.500(2000) specifications.

These include: related entries, a mapping of X.500 protocols (DAP,DSP,DOP, and DISP) directly over TCP/IP without the middle layers of stack, extensions for F.510 (the telephone directory-assistance operations), and multi-master replication, based on design input from Telstra.

10. A deadline was sent for 2 weeks to have an update on the merge of the persistent and triggered search documents.

Slides

None received.