2.1.6 LDAP (v3) Revision (ldapbis)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. 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-02-24

Chair(s):

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

Internet-Drafts:

  • draft-ietf-ldapbis-dn-16.txt
  • draft-ietf-ldapbis-protocol-30.txt
  • draft-ietf-ldapbis-filter-09.txt
  • draft-ietf-ldapbis-authmeth-14.txt
  • draft-ietf-ldapbis-url-09.txt
  • draft-ietf-ldapbis-syntaxes-10.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:

    RFCStatusTitle
    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

    ldapbis WG meeting
    IETF 62, Minneapolis, MN USA
    2005-03-10
    scribe: RL "Bob" Morgan


    The meeting was called to order at 1530 by co-chairs Kurt and Bob.

    Kurt reviewed the status of WG documents. The syntaxes and ldapprep documents are ready to be advanced to the IESG. The chairs are seeking a new author for the schema document, to finish up a couple of small issues and get it to the IESG. The models, filter, DN, and URL documents are all approved by the IESG and waiting in the RFC Editor queue. The BCP64bis and roadmap documents are ready for WG last call.

    The strprep document has already been through WG last call, but a couple of issues have recently been discussed on the list, in particular handling of insignificant spaces in substring matching. The latest draft (draft-ietf-ldapbis-strprep-05.txt) contains Kurt's proposed solution to this issue: to conceptually expand foo[space]bar into foo[space space]bar; a rationale is provided in Appendix B of the document. Bob (as co-chair) will assess consensus on this point to try to close the issue. A new topic has to do with handling "failures" in string mapping and whether "troublesome" characters should be permitted. The latest draft takes the position that they should not be, and Kurt (as editor) believes there is consensus on this point. Others present at the meeting (Jim Sermersheim and Roger Harrison) agree with this approach but think more discussion may be necessary.

    Jim Sermersheim discussed the protocol document (draft-ietf-ldapbis-protocol-30.txt). There is still some work to clarify the use of attributes and subtypes in search filters and search selection lists. There has been discussion of TLS layer removal and the effect of changes in TLS ciphersuites. The general approach is to remove from the document prescriptive text that is unnecessarily restrictive to implementations. For example it should not say that a client should "drop all PDUs after sending a closure alert", since the client may want to process a server close message.

    Language will have to be added to cover the security considerations of TLS ciphersuite changes. Kurt suggests that in general security factors will change throughout the life of an LDAP session, and that these are inputs to client and server policy. The standard can't prescribe all the effects since policies will be deployment-specific. For example, the openldap server is choosing to close a connection when its ciphersuite changes.

    Jim commented that some cleanup is needed in the document regarding the use of "PDU".

    Jim will submit a new rev of the document when the WG has come to consensus on these remaining points. The chairs will follow with a message to the list confirming that the new rev is OK, and if so will return the document to the IESG.

    Roger Harrison discussed the authmeth document (draft-ietf-ldapbis-authmeth-14.txt). Changes were made to reflect the consensus on terminology for connection/session/etc. The "association" term still has to be removed. Roger commented that given recent changes the state table has been reduced even more, and may be at the point of no longer being useful in the document, ie it was useful as a design tool but not as documentation. There was agreement on this point. In discussing handling of SASL-expressed authorization IDs, Kurt said it's important to remember that LDAP does not standardize and authorization model.

    Roger noted that a recently raised issue has to do with clarifying how a client should do matching on different types of subjectAltNames in certificates presented by servers via TLS. E.g., matching rules for DNS names are different from those for URIs. The draft RFC 3280bis has guidance on this (for its own purposes), so the LDAP document should base its language on the same matching specs used there. Kurt said that for example if a DNS name is an IDN, that the rule should be to use the toASCII conversion and use the result of that for matching. Roger also noted that the language about authorization factors should be made less prescriptive.

    Roger hopes to produce a -15 rev by April 8, and that that rev would be
    ready for WG last call.

    Kurt reviewed WG milestones. The key milestone is to deliver the entire revised LDAP technical specification to the IESG by April 2005, so this means proceeding with last call on authmeth in April, clearing up any remaining issues with other docs, and issuing a last call for the roadmap document in April. BCP64bis can be WGLC'd in May, and that would conclude outstanding items for the WG.

    Kurt noted that a Paris meeting, if held, would likely consider new work.

    The meeting was concluded at 1620.

    Slides

    Agenda
    IETF 62: LDAP Protocol
    Changes in Authmeth-14