IETF LDAPEXT meeting March 26, 2000 approximately 70 attendees minutes recorded by Mark Wahl 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.