2.1.6 LDAP (v3) Revision (ldapbis)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional LDAPBIS Web Page

Last Modified: 2005-06-27


Kurt Zeilenga <kurt@openLDAP.org>
RL Bob Morgan <rlmorgan@washington.edu>

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>

Applications Area Advisor:

Ted Hardie <hardie@qualcomm.com>

Mailing Lists:

General Discussion: ietf-ldapbis@openldap.org
To Subscribe: ietf-ldapbis-request@openldap.org
In Body: (un)subscribe
Archive: http://www.openldap.org/lists/ietf-ldapbis/

Description of Working Group:

The LDAPv3 "core" specification is RFC 2251-2256 and 2829-2831.
The purpose of this working group is to shepherd these RFCs
through the Internet Standard process.

The group will deliver revised LDAPv3 specifications suitable for
consideration as a Draft Standard. This work will be based upon RFCs
2251-2256, 2829-2831.

The group will deliver a document detailing IANA considerations
for LDAP suitable for consideration as a Best Current Practice.

The group will deliver an applicability statement defining LDAPv3.
This work will be based upon draft-hodges-ldapv3-as-00.txt.

The following areas are out of scope:
- "LDAPv4"

- All LDAP Extensions (LDAPext) excepting StartTLS.

- LDAP Replication (LDUP)- LDAP non-"core" Schema

- Connection-less LDAP (LDAPext)

Goals and Milestones:

Done  Submit LDAP Applicability Statement I-D
Done  Submit LDAP Overview / Data Model I-D
Done  Submit LDAP Protocol I-D
Done  Submit LDAP Attribute Syntaxes I-D
Done  Submit LDAP DN I-D
Done  Submit LDAP Filter I-D
Done  Submit LDAP URL I-D
Done  Submit LDAP User Schema I-D
Done  Submit LDAP Authentication Methods I-D
Done  Submit LDAP Start TLS I-D
Done  Submit LDAP Applicability Statement I-D to the IESG for consideration as Proposed Standard
Done  Submit IANA Considerations for LDAP I-D to IESG for consideration as BCP
Mar 05  Deliver revised BCP 64 I-D to IESG for consideration to the IESG as a BCP
Apr 05  Deliver revised LDAP TS to IESG for consideration to the IESG as a PS
Aug 05  Submit Interoperability Report I-D
Dec 05  Deliver Interoperability Report to IESG with recommendation that revised LDAP TS be promoted to Draft Standard


  • draft-ietf-ldapbis-dn-16.txt
  • draft-ietf-ldapbis-protocol-31.txt
  • draft-ietf-ldapbis-filter-09.txt
  • draft-ietf-ldapbis-authmeth-14.txt
  • draft-ietf-ldapbis-url-09.txt
  • draft-ietf-ldapbis-user-schema-10.txt
  • draft-ietf-ldapbis-syntaxes-11.txt
  • draft-ietf-ldapbis-roadmap-07.txt
  • draft-ietf-ldapbis-models-14.txt
  • draft-ietf-ldapbis-strprep-05.txt
  • draft-ietf-ldapbis-bcp64-05.txt

    Request For Comments:

    RFC3377 PS Lightweight Directory Access Protocol (v3):Technical Specification
    RFC3383 BCP Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)

    Current Meeting Report

    IETF ldapbis WG meeting minutes
    IETF 63, Paris, France
    2005-08-03, 0900-1000
    submitted by: RL "Bob" Morgan

    The meeting was called to order at 0906 by the chairs, Kurt Zeilenga and RL "Bob" Morgan.

    The first agenda item was WG status. Kurt noted that the group is behind in its milestones and needs to finish up. The stringprep and syntaxes documents, which have been through last call, have had some recent changes. These need to be verified as OK with the WG, and moved to the IESG. The bcp64bis doc has been submitted to the IESG. The user schema doc has finished WG last call, and will be sumitted soon.

    Ted Hardie, the WG's AD, asked whether any WG items have dependencies on any of the large number of other ldap-related drafts, and vice versa. Kurt said that there are normative references to the draft-legg-ldap-binary doc, which is intended to be a Proposed Standard. Jim Sermersheim said that he has drafts that reference the old LDAP spec set, these references can be updated to the new spec set if the timing works out. Ted asked if if it is reasonable to reference the old spec set even though the new protocol doc is finished? Jim said that it was necessary since docs want to reference the whole spec set. Kurt noted that the updated TLS spec has been submitted to IETF last call, so there is one less blocking dependency.

    Jim Sermersheim commented on the status of the protocol doc. The IESG had a concern about an ASN.1 item that needs an OID; this will be fixed.

    It was brought up on the list that there is a change in the new protocol doc from 2251 that makes providing a responseName optional rather than mandatory in an error response; this contradicts RFC 2830, which requires responseName in an error response to the StartTLS extended operation. Kurt said he supports the new protocol approach, but thinks the language on this point may need fixing. Ted said the question is whether this is a clarification or a change, and suggested a one-week WG last call to review the proposed wording change, to see whether it needs further IETF/IESG review. A hum-poll was taken in the room as to whether this change is clarification or substantive; the hum favored clarification.

    Roger Harrison commented on the status of the authmeth doc. He said there are four remaining substantive items. One is the retention of Digest-MD5 as mandatory-to-implement, given questions about potential vulnerabilities, and whether an updated Digest-MD5 spec will be produced by the SASL WG. Kurt said the SASL WG is supposed to come to a conclusion on this in a month, so the ldapbis WG can decide based on that. The most likely alternative MTI is simple-bing over TLS. Promotion of TLS seems reasonable these days, but the security community has been negative on further promotion of plain passwords, even sent over TLS.

    Another item is that the authmeth doc recommends that servers have administrative limits to protect against denial-of-service attacks. The question is whether this should really be recommended. Kurt noted that those limits can create a DoS opportunity. JimS asked why this is an authmeth item at all; there is some existing language about this in the security considerations section of the protocol doc. It was agreed that this recommendation be removed from authmeth.

    Another item is that the authmeth doc says that implementations "SHOULD NOT support cleartext passwords unless protected"; it has been suggested that this should say "SHOULD not support by default", since implementations are compelled to support unprotected cleartext passwords by customer demand. It was agreed to make this change.

    Another item is that the doc specifies protection of transmitted passwords but not other data. Kurt noted that the user-schema doc deals with considerations of password storage, but that this is really a protocol issue. JimS said that the protocol doc deals with protection of protocol elements, not data elements. Roger said he would add a consideration regarding general data protection.

    Kurt asked when the next authmeth draft would be produced; Roger said within a week. Kurt said he intended to issue a last call before the end of August. There is also a last call needed on the roadmap doc, and the final fixes to the protocol doc. So it's conceivable to finish the spec set by the end of September.

    Kurt noted that we still need to find someone to coordinate interop reports to support going to Draft Standard. Once the spec set is done, the group can consider next steps, perhaps rechartering to revise published LDAP extensions.

    The meeting adjourned at 9:58.


    None received.