Draft Minutes for LDAPEXT WG meeting in Adelaide

[Mark Wahl <M.Wahl@INNOSOFT.COM>]

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.

END




Mark Wahl, Directory Architect, Service Provider/Infrastructure
Innosoft, part of Sun Microsystems, Inc.'s iPlanet alliance