2.1.9 LDAP Extension (ldapext)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00

Chair(s):

M. Wahl <Mark.Wahl@innosoft.com>

Applications Area Director(s):

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

Current Meeting Report

LDAPEXT Minutes 31-July-2000 1-3pm Chair: Mark Wahl

Recorded by Mark Smith <mcs@netscape.com>

1:05pm Start

Kurt Z.: add grouping at the end?
Mark W.: may come up under charter review

LDUP (Tuesday)
LDAPbis (Wed afternoon)
LDAP Grouped Operations (dinner BOF: 5:30pm near palms)
SP-DNA intro. session (7:30pm in N. meeting room 2)
SP-DNA working groups (8:00pm)
Evolving LDAP Schema Entries (ELSE - not scheduled)
VPIM 2nd meeting - LDAP schema (Thu afternoon)

last call comments handled:
added option for server to selectively apply the dupent ctrl
a control is now returned with each searchResultEntry
allow any LDAPv3 result code to be returned in result ctrl
updated examples, etc.
outstanding issues:
attribute subtypes ignored (goes against X.500 + LDAPv3)
what if returned attr. list does not include dup ctrl attr?
next step: revise and issue another last call

last call comments handled:
main/sync. and async. drafts combined into one document
changes to schema abstraction classes
next step: issue another last call. Mark W. to issue last call.
Kurt Z.: still some outstanding LDAPv2 & charset issues to work on.

Taxonomy doc. is waiting on its dependencies (last call completed OK)
Locating servers through DNS (Michael Armijo) - last call comments
fully qualified domain names syntax and text
conversion of domain names into DNs
security considerations additions (DNS spoofing)
next step: review and reissue last call

Engineering subteam has made good progress over the past 3-4 months
Trying to take the good things from X.500
BNF and ASN.1 clean up
strength of authentication added (SASL issues remain)
management (access control for ldapaci)
subEntries: need to add scoping?
text added on alias derefering and referrals
version of ldapaci: punting (define a new attr later if needed)
security considerations, examples, etc. updated
Other work to be done:
discloseOnError to be moved to a permission ala X.500
browse/read/search clarifications needed
rename to possibly be removed in favor of other permissions
scoping: divide into two attributes (David Chadwick)
implicit vs. explicity deny "conflicts"
support filters in the aci? leaning is towards "no"
subentry issues
specificity of permissions
Jim S.: meetings or mailing list to resolve open issues?
Ellen: get together after this meeting to schedule more face-2-face time
?: replicated area issues not addressed (replication of acis)
Ellen: that is an oversight
Mark W.: time table for new draft
Ellen: by end of August if progress can be made; then issue last call

plan: split into 2 documents
a) superior & subordinate plus general schema, etc.
b) other kinds of references
Bruce Greenblatt (?): what is a superior reference?
Roland: open issue to be resolved
Kurt Z.: global superior (doc a) vs. immediate superior (doc b)
Open issues:
replication related issues
manageDSAIT control definition ("unhide" knowledge info vs. see only knowledge info.)
???: Do we need NSSR?
Roland: 2 places something similar to NSSR is useful:
a) efficient support for one level searches (spot shadowing)
b) master info. below a country node plus org. specific info.
Mark W.: can we publish document a) (immediate subordinates) by end of August?
Roland: yes, hopefully.

motivation: simple, fast anonymous reads
Open issues:
No updates (hard to do over UDP)
No new security mechanisms (rely on ipsec and friends)
Retry scheme using same LDAP msgid to be specified
Bruce G. ?: Active Directory does this today. How does this align?
Leif: Unknown, but it is still early in the CLDAPv3 specification process.
Mark W.: there are at least 3 LDAPv2 CLDAP implementations
Mark W.: wants updates, SASL, etc.

Presentation of resolved issues:
cn is a "may" although it will typically be the naming attribute
auxiliary objectclass
Scoping: Ed assumed it would be derived from the definition of the administrative areas and naming contexts, i.e., this is like an X.501 subentry that does not have a subtreeSpecifier
But: inheritance across naming contexts, etc. is a tricky area
Some implementations (e.g., Novell) "cache" inherited rights across naming context boundaries
Input so far: need scoping for access control
make it clear, regardless
Mark W.: make the default clear and allow subclasses to override the definition
Ellen Stokes: access control spec. currently assumes ldapaci applies from its location down the tree until another ldapaci is encountered (or to the leaves if no additional ldapaci's)
Ed: where can these subEntries be defined? Intent was to limit the locations to a few "well known" areas
David Chadwick: administrative areas and naming contexts need to be treated separately -- be more flexible. Say that subEntries always reside within AA boundaries, i.e., drop naming contexts from the ldapSubEntry specification.
XXX: Agree with David. Note that naming contexts are within one server but AAs can span servers.
Ed: But we don't have a way to denote the AAs in LDAP. Define an auxiliary class to hold an attribute for this.
Mark W.: adopt the one from X.500 (the attribute's value is an OID).
XXX: Does this discussion belong in the ELSE BOF?
Mark W.: ELSE is focused on user schema, not admin./operational schema
David C.: Need operational attr. within each entry to locate the nearest AA. Could also have a list in the rootDSE of AAs.
Ed: Also need a way to decorate ldapSubEntries.
Helmut Volpers: operational attribute vs. aux class
Ed: I find aux. classes more elegant
David C.: Not needed. AAs are implicitly defined.
Kurt Z.: Subentries within subentries. What does each entry apply to?
Ed: Intent was that all subentries that are together are one set.
Mark W.: Could express how nesting is handled (in a specification for a particular flavor of subentry).
David C.: This would disallow one subentry to hold two kinds of info., e.g. replication and access control
Mark W.: Typically they would be separate anyway.
Next step: Ed to initiate discussion on the list.
Robert Byrne: Should demonstrate how many applications really need scoping vs. those that do not. If there are many applications, we should address it in a common way but if not we can leave it up to each application.
Ed: Trying to avoid copy/paste of subtreeSpecifier from X.500. People can use that today if they like (MUST X.500 in RFC 2251)
Kurt Z.: Why do we need this if we have X.500 subentries already?
Ed: Doesn't allow nesting of replication subentries.
Mark W.: Doesn't allow for other naming attributes.
Ed: Will need to clarify this point.

Charter Review (Mark Wahl led discussion; elect. slides)
Probably need one or two more IETF meetings to wrap up current work
Other work to be done
Simple extensions
Complex extensions (requirements needed)
LCUP
operation grouping
families of entries
schema issues
Schema specification issues (some specs. are circa 1991)
LDAPv3 bug fixes (how to move to DS)
Documents LDAP depends on, e.g., SASL.
Patrik F.: area directors want two working groups
a) core protocol group to focus on MUSTs (attend the BOF)
b) optional extensions as a separate group
Patrik F.: What else is needed to take LDAPv3 to DS?
Next steps: attend the LDAPbis BOF
rechartering discussion w/ADs and so on.

Non Work Item - Matched values only - David Chadwick (elec. slides)
Simplified approach specified; new I-D released in July.
Next steps: new draft followed by last call
remove complex examples (no longer interesting)
add/keep 3 useful examples
take into account recent comments
Open issue: some people say this work is not needed.
Mark W.: the matched values filter is not the same as search filter
David: Yes, it is simpler. Just the basic filter items. Subset.
Helmut Volpers: So I can't use the same filter in both places?
David: Yes, the use of the filter is different.

Non Work Item - Password extended op - Kurt Z.
Submitted to area directors

Non Work Item - Auth Password - Kurt Z.
Still some open issues; to be discussed on the list.

Non Work Item - Password Policy - Jim S.
Almost ready for last call
Will reissue with replication related fix.

Non Work Item - Reply Signatures (no one to represent this)

Non Work Item - LDAP Grouping discussion
Mark W.: motivation comes from LDUP (grouping of repl. updates)
Also, various transaction drafts.
Also, bulk update (LBURP)
Beginning and ending (framing) is useful. But semantics are challenging to specify. ACID? A stream of operations?
Kurt Z. draft specified semantics using an OID.
Many people working on this at the same time. We need 3 things:
- a requirements document
- framing
- semantics of grouping (several documents?)
Roger Harrison: Mark's comments stand: this is generally useful.
Kurt Z.: Need to get on the same sheet of music, but there are some semantic differences. Should have an engineering team meeting.
Mark W.: 5:30pm today!
XXX: Multiple groups on the same connection at the same time.
Mark W.: Yes, if control is used.
XXX: Not going to use the word "transactions?"
Mark W.: ACID is not needed for everthing. Let's do the core work and let the struggles continue where there are hard issues)
Rick Huber: Replication is a useful property of directories. Make sure we take that into account.
Kurt Z.: Single master only?
Rick: Disagree.
XXX: There is somewhat of an analagous situation in the SCSI world: linking of commands (e.g., sequence plus link flag)
Mark W.: One interesting thing is that operations need not be performed in the order sent by the client.

Send slides and presos. to Mark W.

2:50pm Break.

Slides

None received.