Last Modified: 2005-06-27
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 |
RFC | Status | Title |
---|---|---|
RFC3377 | PS | Lightweight Directory Access Protocol (v3):Technical Specification |
RFC3383 | BCP | Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) |
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.