2.1.9 LDAP Extension (ldapext)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99

Chair(s):

Tim Howes <timhowes@yahoo.com>
M. Wahl <Mark.Wahl@innosoft.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: 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

Current Meeting Report

Minutes of LDAPEXT
Taken by Mark Wahl <M.Wahl@innosoft.com>
November 10, 1999

1. Status of Completed Items

LDAP Extension for TLS, Recommended Authentication Methods, DIGEST-MD5 have completed Working Group last call and are in the hands of the IESG.

Server-Side Sorting Control, which was waiting on Simple Paged, is now in IETF-wide last call and is expected to become a Proposed Standard RFC.

Jeff Hodges has unresolved comments on Access Control requirements which he will send to the document authors and WG chairs.

2. Items soon to enter WG last call

The virtual list view and Duplicate Entries drafts have been waiting on Sorting. Now that sorting is gone into IETF-wide last call, the WG chairs will issue WG last call on these drafts soon after the meeting. They are expected to become Proposed Standard RFCs.

3. C API

The latest draft -04 which is in last call has small editorial changes and bug fixes.

There has been some discussion on the list about the security considerations section, for handling credentials and identities with server referrals, that will be addressed during last call.

There is agreement to improve error reporting for functions which do not take an LDAP* as an argument. The authors of the C API and Kurt Zeilenga will have an engineering discussion to arrive at a suitable approach.

Behavior in multithreaded environments is covered by a separate draft which is not part of this last call.

4. Java API

There were no comments on the Java API.
F(
5. ACL model

As Ellen Stokes was not present, discussion was deferred to the list.

Paul Leach and Jeff Hodges have comments which they will provide to the authors.

Since there has been significant discussion on the list, a new draft is expected soon from the authors.

6. Server Location

The draft-ietf-ldapext-locate-00.txt describes how SRV records are to be used to discover LDAP servers. Paul Leach to investigate whether there are any IANA considerations. Mark Smith requested a reference added to RFC 2052 or its successor for the algorithm clients should use to choose the correct server.

There were no other significant issues raised on the taxonomy or discovering servers through DNS.

We will plan to issue last calls on these drafts soon, with the intention that draft-ietf-ldapext-ldap-taxonomy-00.txt will become Informational and draft-ietf-ldapext-locate-00.txt will become a Proposed Standard RFC.

7. Referrals

A work item is the definition of how to manage references between LDAP servers. An earlier draft had specified both the 'simple' behavior, where there is both hierarchical name subordination and knowledge of all the subordinates, names, as well as a more complex behavior to handle potentially overlapping or unknown naming contexts. The former was broken out into draft-ietf-ldapext-namedref-00.txt, the latter does not exist in an IETF draft at present. There is a competing proposal for the former which also covers several inter-X.500-server knowledge cases. David Chadwick was not present and so the technical issues were not discussed. The authors are requested to ensure that by the next meeting we have a single base document on the simple referral behavior that is suitable for last call to become a Proposed Standard.

8. CLDAP

There is not yet a draft on CLDAP, although there are several people interested in writing and implementing it. The authors are requested to discuss and have a draft before the next meeting. If not, this item might be dropped from the charter.

9. Persistent / triggered search

No change in their text since last meeting, so not discussed.

10. LDAP error codes

draft-just-ldapv3-rescodes-00.txt gathers information from X.511 and presents a glossary, table and operational guidance for handling of the error codes in 2251. It does not cover error codes defined by extensions. The authors consider adding flow charts to a subsequent revision. There were several requests however to ensure that flow charts were illustrative examples and not prescriptive, so as to not over-constrain server impementation.

The editor of the core LDAPv3 protocol intends to add this text to the next revision of 2251. A discussion of what status this document as an RFC would have if until that time: If the information changes or updates X.511 or RFC 2251, or if 2251 is underspecified such that this is necessary to implement it, it should be a Proposed Standard which updates 2251, otherwise it should be Informational. The WG chairs, ADs and document authors will discuss this when the draft is ready for last call.

LDAPv3 Result Codes: Definitions and Appropriate Use
LDAPExt Working Group
IETF - November 1999

New draft
edited by Kristianne Leclair (Entrust), Jim Sermersheim (Novell), Mark Smith (Netscape), Mike Just (Entrust)
Available at IETF web site
draft-just-ldapv3-rescodes-00.txt
Posted to LDAPExt mailing list on Oct 27

Draft purpose
RFC 2251 unclear
refers to X.511, but who does?
Gather information into a single source
Intent is to aid
directory developers as to what error to return
application developers as to what error to expect

Draft contents
Glossary
classification of result codes
definition for each result code
Operational guidance
what result to return in case of error
Table
matching each operation and their applicable errors

Next version
Add a Table of Contents
Incorporate comments from group
Add flow charts
possibly replacing or complementing Section 4

How to progress?
Obtain comments
Does draft accomplish what it intended to accomplish?
Long-term?
Incorporate in next version of RFC 2251
Short-term
Standards track in LDAPExt
Last call after March meeting

11. Dereferencing Match

draft-moats-ldap-dereference-match-01.txt is an extensible matching rule which allows indirection through DN-valued attributes during filter evaluation. Its side effects are that the internal state of a filter tree changes from being a tri-state value to entries, and that it is not known whether it could be efficently implemented in a distributed directory. There are several other issues, including whether the service could be provided with a combination of families of entries feature and alias objects, whether it should be specified as a matching rule, search control or extended operation, and how it interacts with weakly consistent replication.

There appeared to be consensus that this work was interesting but not yet ready to be a work item or Proposed Standard. The authors and implementors will prepare an Experiment and produce an Experimental RFC, so that experience may be gained with its use.

Slide 1:
draft-moats-ldap-dereference-match-01.txt

Ryan Moats (AT&T), Jerry Maziarski (AT&T), John Strassner (Cisco)

Slide 2:
Extended Matching Rule that allows dereferencing of DN pointers in server
Simplifies client complexity and round trip time
Standards Track

Slide 3: Dereferencing Match - Example 1
find phone number and building of all managers of any building
(sub, manager:<oid>:=(objectClass=person), (phoneNumber, building))
filter to find phone number of managers of building 12
(base, manager:<oid>:=(building=12), phoneNumber)

Slide 4: Dereferencing Match - Example 2
Find policy rules for outbound traffic for routers with IP Address
192.128.170.x:
(sub, (policyRulesAuxContainedSet:<oid>:=&(ipAddress=
?192.128.170.*?)(qosPolicyRules:<oid>:(QosPolicyDirection=2))), ??)

Slide 5: Dereferencing Match - Side Effects
Filter generates separate objects rather than boolean that applies to
current object of search
Filter rules complex: what is legal?
Legal combination
&(objectclass=fancyconnectiontype)((targetDN:<oid>:=(&(objectClass=dmtfActiv
eConnection)(trafficType=2))))
Illegal combination
|(foo=bar)(foo=barshelf)(&(objectclass=fancyconnectiontype)((targetDN:<oid>:
=(&(objectClass=dmtfActiveConnection)(trafficType=2)))))

Slide 6: Implementation?
Chadwick: use aliases in families of entries in place of multi-valued
pointer attributes
Pro: Servers already have alias dereferencing
Con: Acceptance of families of entries (that include aliases)

Slide 7: Net Steps?
>From mailing-list:
- Need correct syntax OID for matching rule
- Need more discussion (and an example) of how referrals are handled query rewriting using LDAP URLs
- Clarify impact of server side limits
- Add more clarity in the security considerations

Is extended matching the correct approach?
Would a control be better?

Add to WG charter?

12. Extended Partial Response

draft-rharrison-ldap-extpartresp-00.txt specifies an approach of how an extended request can return multiple response PDUs, similar to how a search request returns multiple entries and references followed by a final result.

There are several potential applications of this concept. One would be operation status notification, although this could be done with SNMP, unsoliticed notifications or server-specific operation status subentries.

The editor of the core LDAPv3 protocol will take this concept into account for the reissue of 2251.

13. Password Policy

Jim Sermersheim presented draft-behera-ldap-password-policy-00.txt, which describes a password policy object and password information. A planned revision will remove the modify and compare mechanisms, and remove references to the 'userpassword' attribute. (A separate draft is in preparation for the password hash encoding indications.) Issues under consideration include how to specify the linkage between policy entries and the entries governed by this policy, how to operate under weakly consistent replication, and how to support multi-valued password attributes.

LDAP Password Policy
draft-behera-ldap-password-policy-00.txt

Password Policy Overview
Used to administer password related policy
pwdPolicy object class
Used to create policy for users. Hold info like:
Intruder detection policy
Password expiration policy
Password modification policy

Overview (cont.)
pwdInfoObject object class
Holds password information about a specific entry:
Intruder detect resets
expiration info
modification info

Changes being made to the draft
Remove modify/compare mechanisms and references to userPassword
Incorporate other feedback from the WG list
fix return codes
address V2 concerns
provide clarifications
...

Issues being resolved
Define the association between pwdPolicy and pwdPolicyObject
A one to many relationship between policy and entries
Grouping could be done by:
structural relationship (subentry - subtree)
group inclusion
reverse group inclusion
Work out algorithm/efficiency problems

Placement and Category
Is this an LDAP-EXT WG item?
Should this be a standards track document?

14. LDAP subentries

draft-ietf-ldup-subentry-01.txt describes a subset of X.500 subentries which could be useful for holding DIT policy information, such as subschema or password rules. This is in the LDUP working group as it is being used for replication agreement modelling. When LDUP is ready with this draft, a coordinated last call will be done between LDUP and LDAPEXT for it to become a Proposed Standard.

Slides

None received.