IETF LDAPEXT Meeting Minutes December 9, 1998 Reported by Mark Wahl 1. Introduction Two topics was added to the draft agenda that had been sent to the list earlier in the week: families of entries and X.500(2000) update. Discussion on root DSE attributees was referred to the list. 2. Mark Wahl briefly summarized the drafts that had completed last call. The mandatory-to-implement authentication (MTI) drafts, draft-ietf-ldapext-authmeth-03.txt, draft-ietf-ldapext-ldapv3-tls-04.txt and draft-leach-digest-sasl-01.txt had gone through last call and would be sent to the Area Directors to be progresed as Proposed Standard RFCs. This resolved the issue of a lack of MTI non-cleartext password authentication mechanism that was present when the LDAPv3 drafts were completed. The drafts on language tags, dynamic entries and simple paging had already completed working group last call, and had been waiting for the MTI authentication issue to be resolved. At the time of the meeting, the following drafts were in last call: draft-ietf-ldapext-vlv-02.txt, draft-ief-ldapext-sorting-01.txt, draft-ietf-ldapext-x509-sasl-00.txt, draft-ietf-ldapext-c-api-01.txt and draft-itef-ldapext-acl-reqts-01.txt. 3. Ellen Stokes gave an updated proposal for an Access Control model. This proposal is baesd on defining a standard way of manipulating access control, without requiring a standard access control information transfer encoding between the managing client and server. Access control policy information would conceptually be stored in the directory, but clients would use controls and extended operations to set access controls, get effective access rights and list subject's rights. This would not forbid there being one (or more) possible formats in which the data would actually be stored in servers, but would allow clients to interoperate to a degree with servers whose access control format was unknown to them. A straw poll showed there was interest by implementors in this approach. Discussion focused on two main topics, the need for a common representation format, and the form of subject identity. A common representation of access control information is needed for replication, either through the replication protocol being developed in LDUP, or informally in LDIF files, which do not exchange operations, but the entries themselves. The subject identity in the proposal is in the form of a DN. Security protocols being done in CAT and other working groups use a more generic ( mechanism + mechanism-specific identity object ) format. Another approach would be to have clients ask the server to map their authentication mechanism-specific identity into a DN, which the client could then use in access control operations. 4. Mark Smith reviewed the LDAP C API draft status. LDAP C API Slides Presented at IETF 43 in Orlando by Mark Smith Slide 1 of 3 (overview): - Draft has been around for a long time and is widely deployed. - Tradeoff between compatibility and perfection of API. - Pressure from both sides. - Current draft passes the "It is useful and it works for many people" test with flying colors. Slide 2 of 3 (open issues that are currently listed in the draft and proposed resolution): - 23.1 Threading ==> extension doc. - 23.2 TLS ==> extension doc. - 23.3 Referrals client control ==> add now? - 23.4 IPv6 compatibility ==> address now - 23.5 SASL API std? ==> later - 23.6 Non-UTF8 charsets ==> note and put in extension doc. - 23.7 LDAP session options ==> ? - 23.8 Rebind callback ==> add now - 23.9 API extension mechanism ==> nearly done Slide 3 of 3 (other open issues that were raised on the mailing list and proposed resolution): - A. Use of 'const' in LDAP ==> add as a SHOULD - B. LDAPv2 compatibility ==> ? - C. Use of 'int' vs. LDAPINT32 ==> ? - D. 'ldap.h' header file requirements ==> add now - E. Finer grained client side timelimits in ldap_set_option() ==> extension - F. Document incompatibilities with RFC 1823 ==> later - G. BER bug fixes and clarifications ==> address now - H. Improve non-blocking I/O and select/poll support (for multiprotocol applications) ==> extension - I. Opaqueness of structs; use of arrays ==> the right tradeoff has been made; do nothing. 5. Signed Operations There were few issues noted with the signed operations document, and there was rough concensus that EXPERIMENTAL was the best status for this document at present. One concern was that the title did not quite reflect the contents of this document. 6. Referrals The referrals draft is being split into two parts: one part with the return of referrals by servers holding hierarchically-arranged naming contexts, the second with the return of referrals holding mesh or index information. 7. Jim Sermersheim presented his draft on the return of Duplicate Entries in search results. This was intended for generating a sorted listing when the sort key attributes are multi-valued, and for handling group entries with many members. There was also interest in having range queries on attribute values, so that a client could retrieve some but not all values. This would help with managing an entry with a attribute containing a large number of values, but not with the sorting problem. There was concensus that this would should progress on the standards track. 8. David Chadwick requested the group's input on the issue of representing Compound Attributes, which collect a set of related attributes in a package that is distinct from another set of attributes associated with an entry. (An example might be a person's sets of work and home contact details.) The X.500 standards community was considering two approaches: 1) Attributes could contain an id and a set of attributes. There would be new controls like allInnerValues for operating on attributes inside of attributes. 2) A family of entries. Below a parent entry would be children entry, one for each attribute group. A preference was expressed for the family of entries approach. This would allow existing DIT schema and access control rules to govern these compound attributes more easily. There was concensus to investigate this issue for LDAP directories as part of the LDAPEXT working group. Also, Mark Wahl took an action to document the use of attribute option labels as another simple approach of building compound attributes. 9. David Chadwick presented the other new services being added into the X.500(2000) specifications. These include: related entries, a mapping of X.500 protocols (DAP,DSP,DOP, and DISP) directly over TCP/IP without the middle layers of stack, extensions for F.510 (the telephone directory-assistance operations), and multi-master replication, based on design input from Telstra. 10. A deadline was sent for 2 weeks to have an update on the merge of the persistent and triggered search documents.