2.1.9 LDAP Extension (ldapext)

NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 03-Feb-00

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

IETF LDAPEXT meeting March 26, 2000

approximately 70 attendees

minutes recorded by Mark Wahl <M.Wahl@innosoft.com>

1. Introduction

There were requests to last call both the result codes and vendor info drafts.

Bob Morgan also asked for a schedule for the reissue of RFC 2251 etc.

2. Server Location

The authors of the server location draft were not present, but Bob Morgan summarized the issues he had already raised on the list and would like to have integrated into the reissue.

Questions asked included:

- Are there problems with converting dc-based DNs to DNS names? what are the character set restrictions?

- If client can't find the SRV record with a exact lookup of the DNS name, should it walk up the tree? If not, then does this need to be explicitly called out?

3. Access Control

Presentation by Ellen Stokes

Access Control Model Updates

- Do BNF per RFC 2234

- Add back multiple list of attributes (need consensus on collection)

- Granularity of 'write' permission (need consensus) includes all facets of ldap modify operation, or separate into modify/add, modify/delete, ...

- Clarification of interactions of precedences and evaluations add algorithm so nothing intuited from examples

- Misc editorial / clarifications

- Add 'authenticated' pseudo-user (need consensus)

- Versioning ldapACI for extensibility (need consensus), family OID new (future) access control attribute, other?

Access Control Model Updates

- IP address type format (ala iPlanet) implementation: MUST, SHOULD, or MAY (need consensus)

- KerberosID format: look at generalization aligned with authmeth formats

- Add matching rule (open discussion)

- State that attribute descriptions (cn;lang-US is allowed); Inheritance/subtyping (open discussion)

- Should user need both 'add'(object) and 'write' (attributes) to add a DN/objects and its attributes? (need consensus)

- Do not currently have a way of allowing someone to access something they know exists and not have access to something they don't know exists (open discussion)

Kurt noted that this was not solving the Server-Server problem.

The main discussion was on the combination of models: is this a subset for all vendor's acls to be extensions, is this in force at the same time on the same entries as another acl model, or would the deployer map out a portion of the DIT to be governed only by this access control model, while others are governed?

The implementors will be discussing this question among others of the interaction between vendor and standard access control frameworks, with the goal to assist Ellen in suggesting any changes needed to improve this draft before the next meeting.

4. C API

The editor of the C API draft, Mark Smith, was not present. Kurt Zeilenga described the current state of discussion he was having with Mr. Smith as being closer to resolution than before.

5. CLDAP

Roland to develop and publish a specification soon after the meeting.

6. Subentries

Ed Reed is writing a draft of subentries for the LDUP WG.

Discussion topics included:

- is cn a must or may? If may, is this class combined with other aux classes to provide the naming attribute?

- is the class structural or auxiliary? should other classes inherit from it for specific kinds of subentries or simply be auxiliaries?

- how does this impact RFC 2251/2252's description of the subschema?

Stephen Legg to provide comments to Ed Reed on how this can interact with X.500 servers. Ed Reed will be revising his draft; and the goal is to have a combined Last Call between the LDAPEXT and LDUP working groups.

7. LCUP

The LCUP draft by Olga Natkovich attempts to unify the goal of the persistent search, triggered search and dirsync drafts. It allows clients to synchonize their caches with the server and can also be used by meta-directories and event triggers. It is not intended for LDAP server-server communication, which is the goal of the LDUP protocol.

Unlike triggered search, it does not need the changelog, unlike dirsync it provides for notifications, and ulike persistent search it allows clients to obtain changes that were made earlier when the client was disconnected. The server does not need to store per-client state for each client that uses this feature.

At the request of the chairs and ADs, this work will be moved to the LDUP working group.

8. Vendor Information

Mark Meredith's vendor info draft was presented by Roger Harrison.

Storing Vendor Information in the LDAP Root DSE draft-mmeredith-rootdse-vendor-info-02

Overview

- Specifies 2 new attributes that MAY be included in the Root DSE.

- vendorName

- vendorVersion

- Used to advertise vendor-specific information.

- Supplement Root DSE attributes currently defined in section 3.4 of RFC 2251.

Motivation

- Specific implementations may have flaws such as

- Functionally incomplete implementation

- Bugs not found before distribution & deployment

- Needed in the "real" world.

- Unnecessary in an ideal world.

- Application developers need this information to write interoperable apps, and they are currently forced to poke and prod.

Attributes

- vendorName

- Contains a single string which represents the name of the LDAP server implementer. (e.g. "Novell, Inc.")

- vendorVersion

- Contains a single string which represents the version of the LDAP server implementation. (e.g. "1.5")

- Contrast with the supportedLDAPVersion attribute which specifies the versions of the LDAP protocol supported by the server implementaion.

Usage

- Client implementations can use vendor information to work around implementation flaws as needed.

- Client implementations MUST NOT use vendor information to discover the supported features of an LDAP implementation.

- Client implementations SHOULD accept any vendorName and vendorVersion value.

- Unrecognized values MUST be assumed to be functionally complete and correct.

- Client implementations SHOULD work with implementations that do not publish vendorName and vendorVersion.

Conclusion

- This draft specifies much-needed functionality.

- A fair amount of discussion has already occurred on the mailing list.

- We feel that the current version of the draft accurately represents the community's point of view.

- We propose that this draft be considered for RFC status.

Patrik Falstrom and Bob Morgan recommended MUST rather than SHOULD for interop

with those servers which do not publish.

Questions included:

- was this to be used for feature discovery? If so, would servers be configurable to lie to clients?

- how to handle multiple products from a single vendor?

- how to handle patches?

- If the presence of 'bugs' is dependent on configuration state, how to represent this as a version and do equality match?

9. SP-DNA

Farzi Khazai introduced a 'bar bof' on Service Provider Directory-enabled Network Applications. This activity will develop information, security and application models for the directory in service provider environments. The BOF will investigate the relationship of this activity and the IETF. More information at www.sp-dna.org.

10. Password drafts by Kurt Zeilenga

Kurz Zeilenga presented his two password-related drafts. The authpassword is used for hashed passwords, derived from RFC 2307. An extended operation for password modification separates storage from access. Helmut Volpers and Ed Reed questioned the need for these specifications: could not userPassword continue to be used; why should servers not simply hook into the modify operation to change passwords.

11. Password Policy

LDAP Password Policy, presented by Jim Sermersheim

draft-behera-ldap-password-policy-01.txt

Prasanta Behera - prasanta@netscape.com

Ludovic Poitou - ludovic.poitou@france.sun.com

Jim Sermersheim - jimse@novell.com

Problem Description

- Many LDAP implementations have password policies such as:

- Intruder detection

- Password expiration

- Password updates

- Implementations differ, we need to standardize

- This will increase interoperability.

Types of Password Policy

- Two general types of policy are described:

- Password Usage (intruder detection)

- Account may be locked after a number of failed bind attempts within a given timeframe.

- Password Modifications (add / change)

- Expirations (expirations warnings, grace binds)

- Password History (restrict repeated passwords)

- Minimum Age

- Password Syntax and Minimum Length

Password Policy Information

- pwdPolicy Object Class

- Holds administrative password policy information for a set of users such as:

- min and max age, expiration warning policy

- whether to check syntax - min length

- number of passwords in history

- max # of failures, whether to lock on intruder detect

- whether user is allowed to modify.

- if old pw is required to modify

Password Policy Info (cont.)

- Password Policy State information

- Set of operational attributes on each entry

- last changed time

- account locked time

- expiration warned, grace remaining

- failure time

- password history

- password has been reset

Password Policy Control

- Server control sent to client

- Warn of expired/expiring password

- Report password-related errors

- expired password

- locked account

- modification not allowed

- bad syntax

- new password has been previously used

- etc.

Changes since 00 version

- Generalized password attribute

- Not limited to userPassword

- pwdPolicyInfoObject is gone

- Use operational attributes instead

- Initialization section is gone

- Replaced with default behaviors

- Combined separate controls into one

Changes since 00 version (cont.)

- Removed reliance on error messages

- Overhauled and tightened implementation sections

- General clean-up

- Fixed error codes (names and values)

- Removed redundant information

State of draft

- Draft is Proposed Standard - personal submission

- This is the second version of the draft (Thanks to LDAPEXT WG for reviewing)

The goal for this document is to become a Proposed Standard.

12. Result Codes

LDAPv3 Result Codes: Definitions and Appropriate Use

LDAPExt Working Group

IETF - March 2000

Mike Just - Entrust Technologies

draft-just-ldapv3-rescodes-01.txt

edited by Kristianne Leclair (Entrust), Jim Sermersheim (Novell), Mark Smith

(Netscape), Mike Just (Entrust)

Available at IETF web site

Posted to LDAPExt mailing list on Feb 25

Draft purpose

- RFC 2251, X.511 incomplete, ambiguous

- Gather information into a single source, refine as appropriate

- Intent is to aid

- directory developers - what error to return

- application developers - what errors to expect

Draft contents

- Glossary

- classification of result codes (based on X.511)

- definition for each result code

- Operational guidance

- what result to return in case of error

- Matrix

- result code/operation pairs

What's next?

- Post -02 after meeting

- Incorporates comment from the list

- Last call for -02

- Ultimately incorporate into update of RFC 2251

As there is text which updates RFC 2251/X.511, draft -02 will go to last call to become a Proposed Standard RFC.

13. Schema modification

Do No Harm

Bob Moore

LDAPEXT WG

47th IETF

The Basic Idea

- Allow non-editorial updates to existing definitions, without requiring new OIDs / labels, provided that the updates

- Do No Harm' to existing, deployed applications.

- The gray area: which applications?

- All that actually exist?

- All conceivable ones?

- All reasonably competent ones?

- Since reasonable people can disagree, there is value in having a standard to enumerate which types of changes 'Do No Harm'.

Strictly Speaking ...

- X.501 doesn't allow this at all:

- The definition of information objects such as object classes ..., which have been registered ... are static and cannot be modified.

- Changes to the semantics of such information objects requires the assignment of new object identifiers [and thus of new labels as well].

The Precedent: SMIv2

- SNMP's SMIv2 (RFC 2578) enumerates the changes that are allowed, for example:

- adding new values to an existing enumeration

- adding new objects at the end of an existing row

- Because these changes are specified explicitly, SNMP applications can be implemented to handle them gracefully

Candidate Change 1

- Adding the OBSOLETE qualifier to a class or attribute type definition

- Hard to see what good OBSOLETE does if this is not allowed

- More interesting question: what should (SHALL?) a server do when it receives operations involving OBSOLETE classes and attribute types?

Candidate Change 2

- Adding a new alias name for an existing class or attribute type

- As long as the original name continues to work as it did before, clients should not be harmed

- This question quickly reduces to a more general one about how aliases are supported in directory servers

- For example, does an entry match only on the class under which it was created, or does it match on aliases for this class as well?

Other Candidate Changes

- Adding a new MAY attribute to a class

- Changing class inheritance in a way that leaves class content unchanged

- Modifying an attribute description to extend an enumeration

- More generally, modifying a description in any way that leaves the meaning of existing values unchanged

Now What?

- Is there merit in the concept of Do No Harm changes for LDAP schemas?

- If so, is there merit in having a standardized list?

- If so, is LDAPEXT / the IETF the right place to standardize it?

- If so, are we ready to add it to the LDAPEXT charter as a work item?

There was interest as this appeared to be a real-world problem. Mark Wahl proposed that this should be its own Working Group, rather than added to LDAPEXT.

Slides

LDAP Client Update Protocol (LCUP)