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:
· Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security
· Access Control Requirements for LDAP
· Authentication Methods for LDAP
· The Java LDAP Application Program Interface
· Persistent Search: A Simple LDAP Change Notification Mechanism
· LDAP Control Extension for Server Side Sorting of Search Results
· The C LDAP Application Program Interface
· Access Control Model for LDAP
· X.509 Authentication SASL Mechanism
· LDAP Control for a Duplicate Entry Representation of Search Results
· The Java LDAP Application Program Interface Asynchronous Extension
· Returning Matched Values with LDAPv3
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 |
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.