Last Modified: 2005-02-24
|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|
|RFC3377||PS||Lightweight Directory Access Protocol (v3):Technical Specification|
|RFC3383||BCP||Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)|
ldapbis WG meeting
IETF 62, Minneapolis, MN USA
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.