2.1.9 LDAP Extension (ldapext)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01

Chair(s):

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

Applications Area Director(s):

Ned Freed <ned.freed@mrochek.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:

draft-ietf-asid-ldapv3-lang-nn.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-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:

draft-ietf-asid-ldapv3-referral-nn.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-nn.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-nn.txt draft-ietf-asid-ldap-java-api-nn.txt draft-ietf-asid-ldapv3-api-ext-nn.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:

Done

  

Submit ID on paged retrieval of search results

Done

  

Submit ID on dynamic directories

Done

  

Submit ID on C LDAP API

Done

  

Submit ID on sorting of search results

Done

  

Submit ID on language tags

Done

  

Submit ID on Java LDAP API

Done

  

Meet at 40th IETF (DC)

Done

  

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

Done

  

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

Done

  

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

Done

  

Submit ID on signed directory information

Done

  

Submit ID on recommended authentication methods

Done

  

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

Done

  

Submit ID on access control requirements

Done

  

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

Done

  

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

Done

  

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

Internet-Drafts:
Request For Comments:

RFC

Status

Title

RFC2589

PS

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

RFC2596

PS

Use of Language Codes in LDAP

RFC2649

E

An LDAP Control and Schema for Holding Operation Signatures

RFC2696

 

LDAP Control Extension for Simple Paged Results Manipulation

RFC2820

 

Access Control Requirements for LDAP

RFC2829

PS

Authentication Methods for LDAP

RFC2830

PS

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

RFC2891

PS

LDAP Control Extension for Server Side Sorting of Search Results

Current Meeting Report

LDAPEXT Working Group
Meeting minutes recorded by Roger Harrison (rharrison@novell.com)

WG Status (Mark Wahl)
* Completed items: sorting, lang tags, dynamic entries, signed info
* acl-model-08: new version needed
* vlv-04: went to IESG but has been pulled back to authors for result code issue
* named referrals: last called on -03; -04 will be IESG last call
* taxonomy -05: waiting on locate
* locate-05: needs a new LC
* C API has not been updated since Nov 00; Mark Smith
* java-api-15: will need to be rev'ed and do another last call
* ldapudp-00: needs rev and LC
* dupent-07: LC'ed at -06, dependent on vlv

Remaining Drafts In Detail
Patrik Faltstrom: IESG wants to close the working group. Outstanding documents
(a) is a WG needed for the documents
(b) if multiple vendors will implement

ACL Model
* Recommend that it be taken off of the charter and perhaps be moved to experimental
* will ask on the list before final decision

Java API
* iPlanet & Novell have both implemented
* probably doesn't need to be a WG item; probably should be progressed to proposed standard
* will ask on the list

Locate Draft
* Roland Hedberg feels that this draft should be WG LC'ed as it is with an eye toward taking it toward proposed standard.
* The following IESG last call will give security area folks a change to raise issues if they exist.
* RL Bob Morgan feels that we should just go to IETF-wide last call.

Taxonomy Draft
* Will follow path of Locate draft.

Named Ref Draft
* Issues raised in previous LC have been addressed. Some significant changes occurred as a result.

LDAPUDP Draft
* We will take this to experimental status as an individual submission.
* No comments on the list recently.

Question: is IRTF doing any directory research? Answer: none that anyone present is aware of.

Conclusion
* IETF ldapext WG will likely conclude. This will be the final meeting of the WG.

ACL -08 (Rob Byrne)
* authentication levels added; opinions vary, but Rob feels this is more manageable
* decision algorithm is more formal
* fixed getEffectiveRights
* IP addresses can be used to deny access when other ACI is also available

Planned changes for -09
* clarification of rename behavior
* correction to ABNF for ipAddress

Comments:
* groups/role expansion will be clarified
* no change in authnlevls versus mechanisms
* ip address subjects - no change
* ACM too complex; will remove 't' and 'p' permissions
* removal of subentries
* will remove the ldapACISubentry for an attribute in rootDSE
* equality matching of ACI
* no change: continue using comp matching
* support for controls
* will propose a way to express required permissions for controls and extended ops

Slides

None received.