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)
| Done | Submit LDAP Applicability Statement I-D | |
| Dec 00 | 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 | |
| Dec 00 | Submit LDAP Start TLS I-D | |
| Dec 00 | SASL DIGEST-MD5 I-D | |
| Done | Submit LDAP Applicability Statement I-D to the IESG for consideration as Proposed Standard | |
| Jun 01 | Submit Implementation Report as I-D | |
| Jul 01 | Submit IANA Considerations for LDAP I-D to IESG for consideration as BCP | |
| Jul 01 | Submit LDAP Revised Specification I-Ds and Implementation Report to the IESG for consideration as Draft Standard |
Current Meeting Report
LDAPBIS meeting notes
52nd IETF, Salt Lake City, December 12, 2001
Kurt Zeilenga and RL "Bob" Morgan, co-chairs
RL "Bob" Morgan, David Chadwick, and Roger Harrison, note-takers
Kurt called the meeting to order at 9AM. Following agenda-bashing, the first item was document status.
The LDAPv3 technical specification (draft-ietf-ldapbis-ldapv3-ts-00.txt) is through IETF last call, and is awaiting (and awaiting) action from the IESG. The IANA considerations document (draft-ietf-ldapbis-iana-04.txt) is in ldapbis WG last call now.
3 documents (draft-ietf-ldapbis-dn-06.txt, draft-ietf-ldapbis-filter-01.txt, draft-ietf-ldapbis-url-01.txt) are already through WG last call and are awaiting implementation reports.
The four larger documents (protocol, authmeth, syntaxes, user-schema) are making progress but still have open issues. Each editor was asked to estimate the date of producing the next revision and the date when the doc will be ready for WG last call.
Kurt said that implementation reports are really about to start; help is once again solicited.
Non-ldapbis documents on which progression of ldapbis documents depend are: a revision of RFC 2234 on ABNF (this has been promised by the document author); a revision of RFC 2222 on SASL (this is in process; a SASL WG may or may not be formed); a revision of RFC 2831 on Digest-MD5 (this is in process); and a revision of RFC 2246 on TLS (there is no apparent activity on this, encouragement is necessary).
Kurt spoke about the IANA considerations document. Comments have been made on the list; Kurt has offered new text for sections 5.2 and 5.3. A new revision will be produced shortly after the close of the last call on 2001-12-17, and the doc should be ready to be sent to the ADs at that point.
Jim Sermersheim spoke about the protocol document. It is now at -05; a change history is in the Appendix. An engineering team was formed after IETF 51 to work on issues with attribute options. It has been observed that different options work in different ways. The team proposes that two kinds of options be defined: (1) tagging (specialization) options, based on the behavior of language tags; and (2) transfer options, based on the behavior of the ";binary" option. For tagging options, values are stored, the options carry inheritance/subtyping semantics, and they are not mutually exclusive. Transfer options, on the other hand, are not stored, are only inherited down supertype chains, and are always mutually exclusive (this applies to the implicit "native" transfer option as well). Other types of options may be defined in the future; any such options would have to describe both interactions among options of that type, and interactions with options of other existing types.
There was discussion of the mutual exclusion requirement. The proposed behavior is that the response to a request with two transfer encodings is undefined. If it is useful to support multiple transfer encodings this behavior could be defined in an extension.
The inheritance model was discussed (see Jim's presentation for diagrams). Four interpretations are possible; it is likely that different implementations choose different ones. Question: is this the same as X.500? Kurt: in general yes, but LDAP is different in supporting not just subtyping of attribute types, but of attribute descriptions. RFC 2251 also mentions option ordering but isn't clear. The revised document will make clear that no semantics are implied by ordering.
Other issues remain, see Appendix C. Jim will issue new drafts dealing with a dozen or so issues every few weeks, so there will be two or three more drafts before last call.
Roger Harrison spoke about the authmeth document. It is now at -02, with changes noted in Appendix F. Terms have been aligned with RFC 2828. State transition tables have been added, but definitely need more scrutiny. Question: what about when the SASL authorization-id is the emprty string? Kurt: this has been clarified in the SASL group: an empty authorization-id and an absent field are treated identically. Question: is Digest-MD5 really mandatory to implement? Answer: if authentication is implemented at all, Digest-MD5 must be implemented. Question: should this document attempt to order authn methods by "strength", and/or document known vulnerabilities? Answer: no to both. There was discussion of the server hostname check in TLS: should this become a SHOULD? No, it must stay MUST, but language can be clarified about permitting the client to have local policy that will affect its behavior upon a failure to match. Question: use of a DN in the bindname field in a SASL bind? Answer: the server MUST ignore this field, the client SHOULD NOT send it.
Roger will produce another draft in January. The document should be ready for last call by March.
Kathy Dally spoke about the user-schema and syntax documents, both of which are now at -01. Syntax items were discussed first. References to ";binary" have been removed. There is an issue on inclusion of schema elements in subschema attributes (?). RFC 2252 apparently changed the DIT Structure Rule list separator character from '$' (as used in X.500) to ' '. At least one implementation (from Adacel, according to Steven Legg) makes use of this. There are a few other minor issues, and one substantial issues, that of binary syntax, see discussion below.
Regarding the schema document, should all certificate-related attributes and syntaxes be removed? Answer: yes, these will be dealt with in PKIX WG documents. Question: what about userSmimeCertificate? Answer: this can be dealt with by PKIX or by the SMIME WG if needed.
Kathy said that the syntax document should be ready for last call by March. The user-schema document should be ready for last call shortly.
Steven Legg spoke about issues with the binary syntax. Note that this is different from the ";binary" transfer option. There have been two interpretations of the ASN.1 data type for values with this syntax: (1) the corresponding type is an OCTET string and the octets are any valid BER of any type; (2) the ANY ASN.1 type. For the "native" transfer encoding, these are indistinguishable. But with the ";binary" transfer encoding, with (1) the string is encapsulated in BER, while with (2) the result is the same as if ";binary" had not been chosen. Mark Wahl commented that his interpretation of RFC 2252 is that the BER-encoding interpretation is invalid, and that RFC 2798 implies this too; and that a standards-track document (draft-skibbie-krb-kdc-ldap-schema-01.txt) is being written based on this. Further discussion revealed that implementations are known to exist with each interpretation. After discussion, the consensus position was that this syntax be removed from the normative portion of the syntax document, and a note be added mentioning the now-deprecated syntax and its problems. A new syntax to meet the requirement for "binary storage" should be defined (but not in ldapbis documents).
Kurt spoke about implementation reports, saying that work would begin in earnest shortly.
Regarding charter milestones: IANA considerations should go to IESG in January 2002. An implementation report Internet-Draft will be submitted by April 2002. The working group should conclude its work by June 2002. The WG will meet in Minneapolis in March but may not meet in Yokohama in July.
Kurt also noted that his individual draft moving LDAP version 2 to Historic status should go to the IESG shortly.
The meeting was adjourned at 11:30 AM.
Slides
Some Changes to Protocol Doc.
Outstanding Issues