NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Kurt Zeilenga <kurt@openLDAP.org>
RL Morgan <rlmorgan@washington.edu>
Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>
Patrik Faltstrom <paf@cisco.com>
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/
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)
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 |
· Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names
· Lightweight Directory Access Protocol (v3)
· Lightweight Directory Access Protocol (v3):Technical Specification
· The String Representation of LDAP Search Filters
· Authentication Methods and Connection Level Security Mechanism for LDAPv3
· IANA Considerations for LDAP
· A Summary of the X.500(3rd edition) User Schema for use with LDAPv3
· Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions
LDAPBIS Meeting Minutes
51st IETF, London, August 9, 2001
Kurt Zeilenga and RL "Bob" Morgan, co-chairs
RL "Bob" Morgan and Roger Harrison, minutes-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 awaiting progress from the Area Directors.
* The DN, Filter, and URL documents,
draft-ietf-ldapbis-dn-06.txt
draft-ietf-ldapbis-filter-01.txt
draft-ietf-ldapbis-url-01.txt
are finished, but are awaiting implementation reports before they can progress further.
* The IANA Considerations document
draft-ietf-ldapbis-iana-03.txt
is ready for working group last call.
* The proposed Overview/Data-Model document has not been written, and does not currently have an author. We will proceed on the assumption that it will not happen.
* The four other main documents:
draft-ietf-ldapbis-protocol-02.txt
draft-ietf-ldapbis-user-schema-00.txt
draft-ietf-ldapbis-syntaxes-00.txt
draft-ietf-ldapbis-authmeth-01.txt
are still being worked on.
Other documents on which this group has dependencies are being tracked. A document to advance SASL to Draft standard status has been submitted, and a SASL WG has been proposed but not yet started. The TLS WG is considering a document to move TLS to Draft standard, but this is still a few months from completion. Question: are we also dependent on ABNF moving to Draft standard? Kurt: It is likely that this will happen by the time we need it; we can always fall back to RFC 822.
Jim Sermersheim talked about issues with the protocol document. The -02 revision includes items agreed to at the last IETF, including:
- subschemaSubentry is single-valued in the root DSE;
- criticality=TRUE not permitted on unbind, adandon requests;
- differences between "unauthenticated" and "anonymous" removed and the four states defined;
- removed use of ExtendedResponse as interim search result since there were no implementations.
About 30 other items are listed in the doc as "pending"; most are trivial. Jim will propose language to the list on "equally capable" referrals. The attribute options vs subtypes issue remains unresolved. An engineering team, consisting of Steven Legg, Skip Sloan, Kathy Dally, Tim Hahn, and Jim Sermersheim will consider the issues and make a proposal to the group within 2 months. Jim and Roger Harrison will work to make sure all authentication-related text is moved into the authentication/security document. Jim will figure out how to incorporate the result-codes document material into the protocol document. The data model document will probably not happen so this material will remain in the protocol document. This implies continued reliance on X.501 for defining these concepts. Jim hopes to have the next revision within 2 months.
Roger Harrison talked about issues with the authentication/security document. This has been reorganized based on inclusion of material from RFCs 2829 and 2830, and the Bind-related material from the protocol document. A text version of the STARTTLS state-transition diagram has been prepared, and will be included if possible. It was noted that it would be normative, so must be correct. Roger noted that "LDAP association" isn't well-defined in RFC 2830. Bob Morgan commented that it was intended to distinguish the LDAP-level connection from the TLS-level connection; this will be clarified. The meaning of "secure authentication function" in RFC 2829 was also questioned. There was discussion on the requirement for a client to discard/confirm server capabilities after TLS is started; do we really expect clients to do this? Answer: Yes. About 20 other issues are listed in the current draft; comments on these are solicited on the list.
Kathy Dally talked about issues with the the syntaxes draft. Equality matching rules were added to several attributes. Kurt said this amounts to adding new features and so should be removed. Tim Hahn said these rules were left out due to oversight, and that their existence was implied, so they should be added. Kurt pointed out that a compliant implementation now might not implement them. This will be discussed more on the list. Kathy asked whether encoding should be specified in this document or in the protocol document. Steven Legg said that because the encoding of various string syntaxes in LDAP is ad hoc, it makes more sense to do the definition of the encoding with the syntax definition; Kathy will use this approach. A question was raised about documenting ";binary". Kurt commented that this applies generally to ASN.1, so it should go in the protocol doc; further, the effect of ";binary" may not be what's desired, eg a cert may be sent as BER, rather than DER, thus destroying it. There was further discussion on this point, leading to the observation that perhaps a warning should be given to always use DER for security objects. More discussion is needed on the list.
Kathy reported that she added a requirement that servers MUST implement syntaxes for supported attribute types. Kurt said this may be an issue: should the same statement be made for matching rules? Maqrk Wahl said that an X.500 server can support an attribute without knowing its syntax; so this probably shouldn't be a MUST. Regarding syntaxes and rules that are desirable but were left out of RFC 2252, Kurt has proposed to add them as extensions, and has written an I-D on this topic; so they will not be in the core spec. Steven noted that case-ignore is a matching rule, not a syntax. Kathy added a NAME option to the BNF for syntax descriptions but it will be removed.
Open issues with the syntax document were discussed. Should OID assignments be moved to an Annex? This could be left to IANA considerations. Those without interoperable implementations can be deleted. Helmut Volpers asked about attribute values vs. assertion values on operations like compare, delete, etc. where the attribute value is different from the assertion value; he will propose a clarification to the editor. Should the text say "subschema entry" or "subschema auxiliary object class"? Kurt suggests "subschema entry (or subentry)" in each use. Kathy thought this would need more clarification. The security considerations section probably needs expansion; Kathy would like some assistance with this. Kathy also suggested adopting Kurt's proposal about white space. Steven Legg would like the [option] element removed from the BNF from objectClass definitions so that it would be "attribute type" rather than "attribute description". This needs to be taken to list since at least one implementation currently uses this for certificates.
Kathy continued with a discussion of the user schema document. Referring only to 2nd edition of X.500, as proposed, means no certificate matching rule, is that OK? It is, cert schema will be in the cert schema doc, so it should be removed from this document. David Chadwick noted that the certificate schema is a work item in the PKIX WG, but that PMI content will have to be separated out. Various other items were clarified in the document. Various open issues were discussed. Should all syntaxes and rules be moved to the syntax document? Yes. Kathy estimated that a new revision would be out in two months.
Kurt discussed the IANA considerations document. The question was put whether this should be published now, or wait for the rest of the ldapbis documents to finish? The consensus was to publish now, as there are no dependencies and any modifications can be made at the time all the other docs are published. So a WG last call will be initiated soon.
Kurt led a discussion of the interoperability report. Workers are still needed on this. Chris Harding of the Open Group has volunteered, and already has test suites in place. LDAP Plugfest datacan be used as well. Question: do the report preparers have to verify the interoperability? No, the implementors merely claim it. Question: does widespread reliance on original UMich code base mean fewer "independent implementations"? This has to be considered on a feature-by-feature basis, but implementors should document their code source for this reason. We will start with filter features, then do DN and URL. These should start to happen in the next month or two.
Kurt led the final discussion on updating milestones in the WG charter. The overview/data-model item will be dropped. STARTTLS will be removed as a separate item. Digest-MD5 will remain on until the SASL WG starts up. The data on the implementation report I-D will be changed to December 2001, with March 2002 as the date for all final drafts.
The meeting adjourned at 11:30 AM.
'draft-ietf-ldapbis-protocol-02'
RFC 2252bis - Syntaxes
Authentication Methods and Connection Level Security Mechanisms for LDAPv3