Minutes for LDAPEXT Meeting at Chicago IETF Reported by Mark Wahl 1. Recommended Authentication Methods for LDAP draft There is a requirement for interoperability between implementations that perform updates to the directory. The IESG had added a note to the LDAPv3 RFCs stating this interoperability would potentially only be possible with exchange of passwords in the clear. Therefore the recommended authentication methods draft and related "Start TLS" draft addressed defining an authentication method better than passwords in the clear that would be mandatory for LDAP implementations to support. It was noted that the mandatory to implement algorithm is not mandatory for any organization to deploy. The Start TLS document passed last call with minor edits. The authentication methods draft did not successfully complete last call, primarily as there was significant discussion on the choice of authentication mechanism. There were four options discussed at the meeting: 1) The document as is: make CRAM-MD5 mandatory for updates, 2) Use another existing SASL mechanism, 3) Wait for a new mechanism to be defined, 4) Make Start TLS (encryption service) mandatory The area director Patrik Falstrom advised the WG that other documents produced by the WG that do not depend on this can go forward to IETF last call, so long as progress is being made on the mandatory-to-implement authentication method issued. This discussion focussed on: - was CRAM-MD5 viable? - is TLS acceptable to client vendors? Many vendors of clients present indicated they planned to implement TLS/SSL, although there were comments that it would not be acceptable to builders of embedded LDAP clients for small devices, and that it was overkill to encrypt an entire session just for a single password exchange. - Was there a need for a single mandatory to implement for all LDAP implementations, or could there be different profiles for different application requirements? - Would a situation in which there were a choice of mechanisms, of which a server must implement ALL but a client AT LEAST ONE, be acceptable? A pre-meeting on applications area mandatory to implement mechanisms had resulted in a plan by Chris Newman and Paul Leach to work on a new protected password mechanism that would be acceptable for use in many application area protocols and replace CRAM- MD5 and RFC 2069. The Start TLS draft will have its dependencies on the recommend authentication methods draft removed, and will progress. Should a new acceptable mechanism become available in a few weeks, the recommended authentication methods draft will have CRAM-MD5 replaced by that mechanism. WG ACTION: Start TLS to IETF last call 2. Access Control The WG chairs had sent a poll on the mailing list on how progress should be made on this topic. The results had been: - Should the WG work on this? Yes - Was the requirements draft generally accepted? Yes - Was the ACL Model draft generally accepted? No - Should X.500 ACLs be investigated further as the basis for LDAP? Yes - Should just a framework, or a framework and model be defined? both A framework draft, based on that of the X.500, will be written and sent to the list before the next meeting. Bob Blakely discussed a new approach for building an access control model: define new protocol operations for "grant", "deny" and "get effective" rights. These could be specified with least common denominator subjects and rights information, and allow clients to modify and test access controls without needing to be aware of the encodings of access control inside the server. A quick poll showed a lot of interest in having minimum semantics, however the majority of the discussion on this approach was centered on the issue of how this information could be replicated. In particular, did there need to be a transfer syntax, and if so, how this would be different from the vendor's own representation format. WG ACTION: the requirements draft to go to WG last call 3. Language Tags The Use of Language Tags in LDAP draft had completed working group last call. It is not dependent on authentication methods. WG ACTION: send to IESG for IETF last call 4. Sorting, Paging and Scrolling There was one question asked on virtual list views: there didn't seem to be a cookie exchange in the protocol, which Mark Smith said was by design. WG ACTION: The Virtual List Views and Server-side Sorting drafts will be sent to working group last call to become standards track. WG ACTION: The simple paged draft will be published as Informational, not as standards track. 5. Referrals The referrals document had gone through last call and significant comments on it were received. This will be split into two separate drafts: one on the hierarchical (superior/ subordinate refererence) use of referrals, and the other on a CIP-like mesh on referrals. The two drafts will progress independently, as the hierarchical part appears to have consensus to move to standards track, while the mesh part is still under discussion. 6. SASL mechanism for X.511 authentication There was not much interest seen at the meeting by vendors to implement or standardize this draft. It will go informational. WG ACTION: send to RFC editor as informational 7. Transactions The draft is going to be revised. 8. Persistent or Triggered Search The two drafts were to be merged into a single draft, and this has not yet occured. At least another revision will be needed. There were comments that the document does not caution safe use on the Internet and there had been little operational experience, so may not yet be suitable for being a Proposed Standard. The document may also need to refine or state its domain of applicablilty as a small number of clients. 9. Signed Operations The Signed Operations draft was not discussed as the authors were not present. Some comments were that it needed better clarification of purpose and a less generic title. 10. LDAP APIs The C API draft is nearly ready for last call after one more revision. The Java draft needs to be revised, and there were at least one set of comments on it.