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.
