draft minutes from Chicago meeting

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

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.