Minutes of LDAPEXT Taken by Mark Wahl November 10, 1999 1. Status of Completed Items LDAP Extension for TLS, Recommended Authentication Methods, DIGEST-MD5 have completed Working Group last call and are in the hands of the IESG. Server-Side Sorting Control, which was waiting on Simple Paged, is now in IETF-wide last call and is expected to become a Proposed Standard RFC. Jeff Hodges has unresolved comments on Access Control requirements which he will send to the document authors and WG chairs. 2. Items soon to enter WG last call The virtual list view and Duplicate Entries drafts have been waiting on Sorting. Now that sorting is gone into IETF-wide last call, the WG chairs will issue WG last call on these drafts soon after the meeting. They are expected to become Proposed Standard RFCs. 3. C API The latest draft -04 which is in last call has small editorial changes and bug fixes. There has been some discussion on the list about the security considerations section, for handling credentials and identities with server referrals, that will be addressed during last call. There is agreement to improve error reporting for functions which do not take an LDAP* as an argument. The authors of the C API and Kurt Zeilenga will have an engineering discussion to arrive at a suitable approach. Behavior in multithreaded environments is covered by a separate draft which is not part of this last call. 4. Java API There were no comments on the Java API. 5. ACL model As Ellen Stokes was not present, discussion was deferred to the list. Paul Leach and Jeff Hodges have comments which they will provide to the authors. Since there has been significant discussion on the list, a new draft is expected soon from the authors. 6. Server Location The draft-ietf-ldapext-locate-00.txt describes how SRV records are to be used to discover LDAP servers. Paul Leach to investigate whether there are any IANA considerations. Mark Smith requested a reference added to RFC 2052 or its successor for the algorithm clients should use to choose the correct server. There were no other significant issues raised on the taxonomy or discovering servers through DNS. We will plan to issue last calls on these drafts soon, with the intention that draft-ietf-ldapext-ldap-taxonomy-00.txt will become Informational and draft-ietf-ldapext-locate-00.txt will become a Proposed Standard RFC. 7. Referrals A work item is the definition of how to manage references between LDAP servers. An earlier draft had specified both the 'simple' behavior, where there is both hierarchical name subordination and knowledge of all the subordinates, names, as well as a more complex behavior to handle potentially overlapping or unknown naming contexts. The former was broken out into draft-ietf-ldapext-namedref-00.txt, the latter does not exist in an IETF draft at present. There is a competing proposal for the former which also covers several inter-X.500-server knowledge cases. David Chadwick was not present and so the technical issues were not discussed. The authors are requested to ensure that by the next meeting we have a single base document on the simple referral behavior that is suitable for last call to become a Proposed Standard. 8. CLDAP There is not yet a draft on CLDAP, although there are several people interested in writing and implementing it. The authors are requested to discuss and have a draft before the next meeting. If not, this item might be dropped from the charter. 9. Persistent / triggered search No change in their text since last meeting, so not discussed. 10. LDAP error codes draft-just-ldapv3-rescodes-00.txt gathers information from X.511 and presents a glossary, table and operational guidance for handling of the error codes in 2251. It does not cover error codes defined by extensions. The authors consider adding flow charts to a subsequent revision. There were several requests however to ensure that flow charts were illustrative examples and not prescriptive, so as to not over-constrain server impementation. The editor of the core LDAPv3 protocol intends to add this text to the next revision of 2251. A discussion of what status this document as an RFC would have if until that time: If the information changes or updates X.511 or RFC 2251, or if 2251 is underspecified such that this is necessary to implement it, it should be a Proposed Standard which updates 2251, otherwise it should be Informational. The WG chairs, ADs and document authors will discuss this when the draft is ready for last call. LDAPv3 Result Codes: Definitions and Appropriate Use LDAPExt Working Group IETF - November 1999 New draft edited by Kristianne Leclair (Entrust), Jim Sermersheim (Novell), Mark Smith (Netscape), Mike Just (Entrust) Available at IETF web site draft-just-ldapv3-rescodes-00.txt Posted to LDAPExt mailing list on Oct 27 Draft purpose RFC 2251 unclear refers to X.511, but who does? Gather information into a single source Intent is to aid directory developers as to what error to return application developers as to what error to expect Draft contents Glossary classification of result codes definition for each result code Operational guidance what result to return in case of error Table matching each operation and their applicable errors Next version Add a Table of Contents Incorporate comments from group Add flow charts possibly replacing or complementing Section 4 How to progress? Obtain comments Does draft accomplish what it intended to accomplish? Long-term? Incorporate in next version of RFC 2251 Short-term Standards track in LDAPExt Last call after March meeting 11. Dereferencing Match draft-moats-ldap-dereference-match-01.txt is an extensible matching rule which allows indirection through DN-valued attributes during filter evaluation. Its side effects are that the internal state of a filter tree changes from being a tri-state value to entries, and that it is not known whether it could be efficently implemented in a distributed directory. There are several other issues, including whether the service could be provided with a combination of families of entries feature and alias objects, whether it should be specified as a matching rule, search control or extended operation, and how it interacts with weakly consistent replication. There appeared to be consensus that this work was interesting but not yet ready to be a work item or Proposed Standard. The authors and implementors will prepare an Experiment and produce an Experimental RFC, so that experience may be gained with its use. Slide 1: draft-moats-ldap-dereference-match-01.txt Ryan Moats (AT&T), Jerry Maziarski (AT&T), John Strassner (Cisco) Slide 2: Extended Matching Rule that allows dereferencing of DN pointers in server Simplifies client complexity and round trip time Standards Track Slide 3: Dereferencing Match - Example 1 find phone number and building of all managers of any building (sub, manager::=(objectClass=person), (phoneNumber, building)) filter to find phone number of managers of building 12 (base, manager::=(building=12), phoneNumber) Slide 4: Dereferencing Match - Example 2 Find policy rules for outbound traffic for routers with IP Address 192.128.170.x: (sub, (policyRulesAuxContainedSet::=&(ipAddress= ?192.128.170.*?)(qosPolicyRules::(QosPolicyDirection=2))), ??) Slide 5: Dereferencing Match - Side Effects Filter generates separate objects rather than boolean that applies to current object of search Filter rules complex: what is legal? Legal combination &(objectclass=fancyconnectiontype)((targetDN::=(&(objectClass=dmtfActiv eConnection)(trafficType=2)))) Illegal combination |(foo=bar)(foo=barshelf)(&(objectclass=fancyconnectiontype)((targetDN:: =(&(objectClass=dmtfActiveConnection)(trafficType=2))))) Slide 6: Implementation? Chadwick: use aliases in families of entries in place of multi-valued pointer attributes Pro: Servers already have alias dereferencing Con: Acceptance of families of entries (that include aliases) Slide 7: Net Steps? >From mailing-list: Need correct syntax OID for matching rule Need more discussion (and an example) of how referrals are handled query rewriting using LDAP URLs Clarify impact of server side limits Add more clarity in the security considerations Is extended matching the correct approach? Would a control be better? Add to WG charter? 12. Extended Partial Response draft-rharrison-ldap-extpartresp-00.txt specifies an approach of how an extended request can return multiple response PDUs, similar to how a search request returns multiple entries and references followed by a final result. There are several potential applications of this concept. One would be operation status notification, although this could be done with SNMP, unsoliticed notifications or server-specific operation status subentries. The editor of the core LDAPv3 protocol will take this concept into account for the reissue of 2251. 13. Password Policy Jim Sermersheim presented draft-behera-ldap-password-policy-00.txt, which describes a password policy object and password information. A planned revision will remove the modify and compare mechanisms, and remove references to the 'userpassword' attribute. (A separate draft is in preparation for the password hash encoding indications.) Issues under consideration include how to specify the linkage between policy entries and the entries governed by this policy, how to operate under weakly consistent replication, and how to support multi-valued password attributes. LDAP Password Policy draft-behera-ldap-password-policy-00.txt Password Policy Overview Used to administer password related policy pwdPolicy object class Used to create policy for users. Hold info like: Intruder detection policy Password expiration policy Password modification policy Overview (cont.) pwdInfoObject object class Holds password information about a specific entry: Intruder detect resets expiration info modification info Changes being made to the draft Remove modify/compare mechanisms and references to userPassword Incorporate other feedback from the WG list fix return codes address V2 concerns provide clarifications ... Issues being resolved Define the association between pwdPolicy and pwdPolicyObject A one to many relationship between policy and entries Grouping could be done by: structural relationship (subentry - subtree) group inclusion reverse group inclusion Work out algorithm/efficiency problems Placement and Category Is this an LDAP-EXT WG item? Should this be a standards track document? 14. LDAP subentries draft-ietf-ldup-subentry-01.txt describes a subset of X.500 subentries which could be useful for holding DIT policy information, such as subschema or password rules. This is in the LDUP working group as it is being used for replication agreement modelling. When LDUP is ready with this draft, a coordinated last call will be done between LDUP and LDAPEXT for it to become a Proposed Standard.