Introduction
The author is the editor of various PKIX and LDAP Internet Drafts, and this was the primary focus of his attention at the Pittsburgh meeting.
PKIX meeting
LDAPv3 Profile <draft-pkix-ldap-v3-03.txt>. This ID is written by the author. It was agreed that this ID should go to last call at end of August and be sent to LDAPExt group as well. Subsequent to his return from Pittsburgh the author updated the ID and it was resubmitted for last call on 2 September.
LDAPv3 Schema <draft-pkix-ldap-schema-01.txt>. There was quite a long discussion about the Schema ID and whether it should go to core LDAP, and be transferred to the LDAPExt group, or should stay with PKIX. It was decided on latter. Consequently the author updated the ID on his return, and a revised version was issued on 8 September.
RFC 2459-bis. This is a revision to the X.509 profile. It was decided to spilt the stable information (i.e. certificate and CRL profiles) from the cryptographic algorithms (section 7). The latter can then be merged into the IDs dealing with algorithms. It was decided to have a section on mandated algorithms and the list will decide which algorithms to mandate, and which RFC to put this in. There are many minor errors in the original RFC e.g. the profile has limited the maximum size of an OID component and of the number of elements in an OID. Also it needs to align name support with the QC draft (e.g. making Pseudonym SHOULD support). There is a misalignment between the profile and X.509 for handling policies and policy mappings. Hopefully the new draft will go to last call at the end of August and will be a recycling at RFC Proposed standard level as there are too many changes from the existing 2459 for it to go to Draft Standard.
X.509 defect There is a lack of clarity in X.509 about how to handle understood critical extensions, can a server ignore them or not? The fix is to mandate that applications act on an extension regardless of its criticality (i.e. they cannot ignore it).
Qualified Certificates. Version 5 was released in July. A new draft with minor clarifications will be released before the end of August and go to last call.
Permanent Identifier. Denis Pinkas introduced this subject. Ideally each real person should have a permanent identifier in his certificate which will track name changes e.g. upon marriage. It will be an optional subject alternate name for a certificate. This will allow you to know if two certificates belong to the same person even if their names are different. The syntax is proposed as a Sequence of optional assigner name (if different to name of CA) and unique identifier. Can be placed in either the DN or ID field of General Names.
Time Stamping Protocol. Stamp-09.txt. This ID has already been to last call, and a few minor changes were made as a result. Time stamping key MUST not be used for any other purpose. The document can now go to the IESG as a proposed standard.
OCSPX. Extensions to OCSP. Intended to be a general framework for asking about certificates. It addresses delegated validation. OCSP is inherently extensible via an OID and octet string. (It also has security weaknesses such as Replay). It was decided to produce a 2560bis Framework document (to fix the defects e.g. module OID is missing, and to prepare for extensions) plus various extension documents such as Delegated/Remote Path Validation and a Delegated/Remote Path Discovery.
Remote Path Processing. A RP asks a RPP server whether a certificate is good for a particular purpose or not. We can use OCSP with extensions (without needing the hash of the CA’s public key) or SCVP. SCVP supports both ASN.1 and XML. This is another example of the Separate protocol vs. Generic protocol with OID extensions issue.
Attribute Certificates Profile. It has been synchronised with X.509(2001). There are 2 outstanding issues. Should we reference 2459 or 2459bis, and what should it reference for algorithms, and for Kerberos ids. It was decided that it should be the latest documents as they will go for last call within one month.
LAAP. (Joinly written by the author and Steve Farrell). This ID probably needs one more revision before last call. A new version will be issued in time for the San Diego meeting.
CMPbis. Some minor changes have been added. Interop testing is under way within the PKI Forum. When this is finished we should issue another draft based on the results.
PKIX Repository Locator. This attempt to address the issue of How to find the certificate of someone in a remote location who has a remote LDAP repository. The ID defines a pkix SRV record type. The author thinks that this work needs to align with the LDAP work on SRV records.
CMP Interoperability Testing. 4 interworkshops have been organised,
1st 2-4 May 2000, second 6-8 June 2000, third 11-14 July, next
workshop 8-10 Aug. A fifth is planned for 5-7 Sept 2000. Participants have
included: Certicom, Cylink, Entegrity, Entrust. TC Trustcenter, SSH and
Sun(Java). They have tested PoP. They will test cross certification. A public
demo is planned for NISSC in Oct 2000. Others who want to join when they are
ready are: IBM, Baltimore, NIST, OpenCA (from Italy), RSA Research and Utimaco.
Lessons learnt. CA policy has a major impact on end entity use of CMP (they need
to collect basic policy items.) A few areas of 2510bis are still unclear.
Conclusions. CMP interoperability still does not exist but they hope to achieve
it by the end of the year. The Chair is Robert Moskowitz, rgm@icsa.net. A web
page will be set up eventually. Bob says he will run a CMC interoperability
workshop if anyone needs it (e.g. with Microsoft).
LDAPExt Meeting
It was noted at the meeting that LDAPv2 is a Draft Standard, whilst LDAPv3 is still only a Proposed standard. LDAPv2 cannot be superseded until LDAPv3 reaches draft status. Consequently it was agreed to propose a new working group, LDAPBIS, whose sole purpose is to push the base set of LDAPv3 standards to Draft status. There was a long discussion about what constituted the base set of standards and eventually an agreement was reached. The base set will be the minimal needed to allow a client and server to interoperate - real applications will probably need additional schema standards to the base set, and possibly some extensions to the protocol. Since the meeting a mailing list has been set up, and editors to the base set of standards have been chosen. Strawman revisions should be produced in time for San Diego.
RFC 2251: Lightweight Directory Access Protocol (v3) - Jim Sermersheim
RFC 2252: LDAP (v3): Attribute Syntax Definitions - Mark Hinckley
RFC 2256: A Summary of the X.500(96) User Schema for use with LDAPv3 - Kathy Dally
RFC 2829: Authentication Methods for LDAP - Roger Harrison
RFC 2830: LDAPv3: Extension for Transport Layer Security - Jeff Hodges
LDAP Data Model <draft-wahl-ldapv3-defns-xx.txt> Mark Wahl
RFC2253: UTF-8 String Representation of Distinguished Names - Kurt Zeilenga
RFC2254: The String Representation of LDAP Search Filters - Mark Smith
RFC2255: The LDAP URL Format - Mark Smith
The IESG now has to approve the new working group.
Administrative Areas. After some discussion it was agreed that the unit of distribution, the naming context, may not be the unit of administration, and therefore policy access controls, for example, will not just reside in context prefix entries. A new subentries draft will be produced that will be a base template for storing policy information in subentries, situated below administrative points.
Matched Values. This ID is edited by the author, and describes how a subset of values can be returned to a Search request. It was agreed that it is now ready to progress to last call after people have had time to review the current draft. A final ID was released in October for last call, after some comments were received.
Duplicate Results. This ID describes how the same entry can be returned multiple times to a Search request, with each return holding different attribute values. It was agreed that this document is nearly ready for last call, and should have one final review by the list. It was subsequently sent for last call in October.
Java API. This ID has progressed well, but when it seems almost ready for last call, some more questions are raised on the list. We were up to version 10 by the meeting, and a new revision was promised for September.
Discovering LDAP servers with the DNS. A method based on the use of DC names and DNS SRV records is proposed in this draft. Something similar is already being used by MS Active Directory. The work is nearly ready for last call.
Taxonomy of finding LDAP Servers collects together all the ways of discovering LDAP servers (including the above). This document is almost ready for last call.
Referrals. A new ID has just been issued on this topic, and this was briefly discussed a the meeting. Of primary concern is how many types of knowledge reference should be standardised in the first document, and how many should be left for later. Probably only superior, subordinate and cross references will be in the first standard.
Transactions. There have been several attempts to standardise a way of submitting transactions to LDAP servers, but none have been accepted so far. There was some discussion of the best way to proceed here, and it was agreed that a control could be added to LDAPv3.
LDUP Working Group
The group is working on replication protocols for LDAP. Unfortunately this meeting clashed with the PKIX meeting and so the author could not attend. The draft minutes are included in Appendix 1. The author has asked the various WG chairs to try to ensure that this clash does not happen again (e.g. in San Diego).
LDAP Access Control BOF
This topic has its own mailing list <ietf-ldapext-acm@OpenLDAP.org>. A meeting was convened to discuss the current ID on LDAP access controls <draft-ietf-ldapext-acl-model-06.txt> issued in July. Many issues were raised and discussed, such as: what rights should be needed for the ModifyDN operation, should policy rights be in a separate subentry or as now in a normal entry, should discloseOnError be made per user rather than per server as now. The ID editor took away the comments and agreed to produce a new ID based on the comments, but this has not yet been forthcoming. There seems to slow progress on this topic, which is unfortunate.
AAA Working Group
The author attended this meeting out of interest, but is not a member of the mailing list. The group is looking for a protocol on which to base its work, and has several possible candidates, as below.
Radius ++
Needs backwards compatibility with existing clients/servers. Needs some mechanism to detect if extensions are understood. Where is this different from COPS and DIAMETER? Need pass through capabilities with router broker proxies and error messages to allow fallback operation.
COPS
Cops defines a framework and generic protocol through which typed values can be passed. It comprises a Request, a Response and a Decision. It is a stateful request response model. COPS can be proxied where the proxy acts as server to a client and a client to the AAA server. It supports redirection, authentication, integrity and confidentiality. It runs over TLS for hop to hop security and CMS for end to end security. It uses SMI namespace and BER encoding. It seems like a good candidate.
Diameter
Allows the protocol path to be different between the NAS and the AAA server in case of node failure. SCTP will soon be published as an RFC. An interworking bake off has been successfully run.
SNMPv3
SNMP can be used for accounting data collection, but might be difficult to do the authorisation and authorisation aspects of AAA. Recommendations of SNMP group: keep it simple, modular, protocol separate from transport, design for growth and migration, make it flexible and configurable to operational environment, costs for features should be borne by those that need them.
The list will decide what direction to take for the AAA protocol(s).
Appendix 1
LDUP WG Meeting, Wednesday August 1, 2000
Meeting minutes recorded by John Strassner
0. Agenda discussed, and no changes were made.
1. "LDAP Replication Requirements"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-03.txt
Editor(s): Russ Weiser, Ellen Stokes
This is an expired draft and needs to be republished in
order for us to
proceed with work on it. By republishing, we
mean that the document must be
published, with no changes
other than an updated revision number. This is
necessary so
that we can refer to it in the upcoming discussions. This
will be done this week
Action: republishing to be done this week; see item 12 below.
2. "LDUP Update Reconciliation Procedures"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-03.txt
Editor(s): Steven Legg, A Payne
This draft has undergone a minor revision, having been
updated to include
the correct use of MUST and MAY as well
as a clarification resulting from
the discussion with Albert
Langer. In addition, the
References and
Security Considerations sections have also
been updated. In summary, it is
ready to go to last call,
but can't until the requirements document is
updated to
reflect the discussions with Albert Langer.
Action: none, pending resolution of requirements draft - see item 12
3. "LDAP Replication Architecture"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-04.txt
Editor(s): Ed Reed, U. Srinivasan, John Merrells
There were open comments from the mailing list regarding
references in
this draft to other drafts. We had a
synchronization problem with these
other drafts, as these
normative references were moving and this draft was
getting
out of sync. This has been corrected, and the normative
references removed.
The only remaining open issue in this draft is the
relationship between
access control and the definition of
naming context. In LDUP, the naming
context is the unit of
replication, but in access control, it is slightly
different
(administration points are defined differently than naming
contexts). Once these changes are made, the document will be
ready for
last call.
Action: this draft will be revised by the end of September.
Depending on the resolution of the issue above, it may be
ready for last
call then.
4. "LDUP Replication Information Model"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-01.txt
Editor(s): Ed Reed
No changes in this document as of now. Reference to ITU UUID
document was
found and will be incorporated. General
reconciliation with the architecture
document is now
necessary. One additional point is that access control
information needs to be replicated, but we don't want to
deal with
inherited ACI yet. This issue needs to be taken to
the list.
Actions:
1) Ed to lead discussion on the list regarding how to handle
replication
of ACI.
2) The next revision of this draft will be published by
the end of
October.
5. "LDAP Subentry Schema"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-03.txt
Editor(s): Ed Reed
Basic problem is that the presence of a subentry causes an
administrative
area to be defined. So the administrative
area may not exactly coincide with
the naming context. The
subentry document needs to be updated to define what
is
meant by each of these terms. The management of
administrative areas,
and how this differs (if at all) from
the management of naming contexts,
needs to be documented.
This challenges us to as to whether replication
needs
semantic understanding of administrative areas. This seems
like a
very thorny issue, and it was suggested that we treat
this as a version 2
problem in order to make progress with
the existing definition of LDUP. This
draft will be revised
to make scoping of LDUP subentry more clear.
Open
issue raised by Kurt is to use a control instead of a
filter mechanism to
make subentries visible. This issue has
been posted to the list.
Action: The next revision of this draft will be published by
the end of
October.
6. "The LDUP Replication Update Protocol"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-01.txt
Editor(s): G. Good, E. Stokes
A few open issues have been raised with respect to the
signatures of
ReplicationStart and other commands. This will
cause the document to be
revised.
The big problem is whether this document should or should
not
use framing. This discussion needs to be taken to the list.
Actions:
1) Ellen and/or Gordon to lead discussion on the list as
to whether this
document should use framing.
2) The next revision of this draft will be published by
the end of
October.
7. "Extended Operations for Framing LDAP Operations"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing-00.txt
Editor(s): G. Good, E. Stokes, Roger Harrison
This work will be subsumed into the grouping operations work
being done
in LDAPEXT and produce a new framing document
(see below).
Action: This draft will be updated by the end of Septmeber.
8. Mark Wahl - Grouping operations
In Adelaide, work was started on taking the existing LDUP
framing
document (which LBURP was using) and generalizing it
so that other
operations could use framing.
One possible use of framing was to add
transaction support
to the directory protocol, but this was decided to be
too
big to tackle. However, there is interest in the use of
framing in
other areas (e.g., for the client to request
locking on entries, or for
certain integrity constraints to
be maintained). One of the desired features
is to change the
referential integrity enforced by a directory server, such
that instead of maintaining referential integrity on an
operation by
operation basis, it instead changes to maintain
referential integrity on a
set of updates (e.g., enforce it
at the end of the operations).
Mark
believes that we need extended operations for
delimiting beginXX and endXXX
operations, and need a
document to cover these associated semantics. Note
that what
is being proposed is that there is a generic way of saying
Begin<insert operation here> and End<insert operation here>.
So the framing document needs to be generalized so that
everyone can use
it. This should be done with a joint last
call with LDAPEXT.
Action: Mark and Roger to work on a revised draft, to be out
sometime in
October.
9. Some deliverables still missing in action...
9a. Mandatory replica management (Ed Reed). Mark has given
us a starting
draft; Ed will work with others and try and
issue this document in
September.
9b. Master-slave and multi-master profile documents are
behind schedule.
Uppilli will take the lead on this work.
Since work has stalled, the
question was asked, is it
beneficial to have profiles that specify how
replication
works for single-master vs. multi-master.
Actions:
1) Uppilli to lead discussion on the list as to whether we
still need
separate profiles for (at least) single- vs. multi-master or not.
2) The next revision of this draft will be published by
the end of
October.
10. Charter Addition for LCUP?
"LDAP Client Update Protocol"
http://www.ietf.org/internet-drafts/draft-natkovich-ldap-lcup-01.txt
Editor(s): O. Natkovich, M. Smith, M. Armijo
The short summary is that LCUP is dirsync, persistent
search, triggered
search, and LDUP replication. There is an
open issues section in the current
draft. PLEASE COMMENT!
Room was polled, and a large majority of the room was
in
favor of adding it (no one was actually opposed). Patrik
asked if
this would conflict with or hold up existing work,
and the answer was no,
there was already a dedicated group
of people ready to work on this that
weren't involved in
other work. This question will therefore be taken to the
list.
Actions:
1) Co-chairs to poll the list to ensure that no one
objects to adding
adding LCUP to the LDUP charter.
2) If no one objects, then co-chairs to propose new
charter to list; if
acceptable to list, then to work with Ads to get our
charter officially
amended.
11. Other business (besides discussion of Albert's
comments): LBURP
We also have an open question of adding LBURP to our
charter. This draft
has been revised since the last meeting
(draft-rharrison-lburp-02.txt).
The changes to the -02 version include adding a new
operation,
LBURPOperationPartialResponse (note name change
from slide). This tells you
what operations have succeeded,
failed, or are still pending.
Remaining
questions - after a brief discussion, it seems
like the ability to defer
operations should be taken out, as
it causes more problems than it solves.
What is the relation between LBURP and the framing document?
Roger will
try and move this document to keep it in sync
with the framing document.
Finally, there wasn't a lot of feedback as to whether LBURP
should be
added to our charter or not.
Action: co-chairs to pose the question of adding LBURP to the list or not.
12. Discussion of LDUP Requirements Document
Discussion about issues raised by Albert Langer. It was
impossible to
judge how to proceed, based on the lack of
discussion that occurred on the
list. So the co-chairs asked
for an independent review. This initial work
was done by
Rick Huber and Ryan Moats. Both will be added as authors of
the requirements document as a result of this work.
Summary of Objections to Requirements
The big four points are as follows:
- No requirement for convergence or
eventual consistency
- No requirement for atomic operations
- No
requirement to support mandatory operational attributes of LDAP
- Definition
of updateable replica inconsistent with multi-master replication
Taking these objections in order...
First point: These seem to be covered by requirements 5.2
and 5.7. But,
since the draft goes to the trouble of
defining 5 different types of
consistency. But, since the
draft goes to the trouble of defining five
different types
of consistency, it would be a Good Thing if the requirements
were stated in those terms.
Action: Suggest adding a requirement for Eventual Consistency.
Second point: there is a requirement for atomicity in LDAPv3
per RFC2251,
section 4.6, and the referenced Tim Howes
quote. So the real question is
whether this is covered in
sections 5.2 and 5.7.
Action: Suggest adding something more specific, as this
would avoid any
later confusion.
Still on this point, we had an atomicity discussion.
Consider the following replication scenario. Servers A, B,
and C
replicate with each other using multi-master
replication. On server A,
attributes 1, 2, and 3 of entry E
are changed (an atomic operation). On
server B, attribute 2
of entry E is changed. Without descending into the
religious
{ ;-) } argument of which method is best, assume for the
moment that the change on B has a later time stamp than the
change on A.
There are three possible options: discard all changes from
A, make
changes from A and ignore B, or make change from A
and then make change from
B.
Note that this is an example of race conditions. If you want
to change
attribute 2 based upon the value of attribute 1,
then since LDAP doesn't
have a true read lock, you can't do
this. It was argued that LDAP does have
a read lock by
virtue of doing a delete-add of the same value (which is
basically a test and set).
So, what should happen? There are three
possibilities:
1. The entire change from A is discarded since it is
atomic and was
superceded by the change from B.
2. The change from A is made and all attributes reflect
the values on A
since the change was atomic, and B is deleted.
3. Attributes 1 and 3 reflect the values from A, attribute
2 reflects the
value from B.
Note that the third case is what would happen in the
single-server or
single-master case. In addition, the third
choice seems to be the most
reasonable choice according to
the time-honored Principle of Least
Astonishment. ;-) There
was overwhelming consensus in the room that this
last case
was indeed what was expected.
This boils down to the following problem - if a set of
requests were
submitted as a group, then the replication
system should treat them as an
atomic group. However, each
operation should be processed on its own for
conflict
resolution (as opposed to the group). Note that the word
atomic
causes problems. In the example scenario, we want the
value to end up with
{1, 2', 3}. It was noted that part of
the problem is in viewing this as
entry-centric, as opposed
to being attribute-centric.
Action: this is a good example, summarizing many of Albert's
objections,
and why it was felt that in this area his
objections were not reasonable. It
should be included in the
new version of the requirements document.
The third point is that there was no requirement to support
the mandatory
operational requirements of LDAP. Ryan and
Rick noted that ModifiersName is
a MAY in 2251 and a SHOULD
in 2252. This is a Bad Thing, and Mark promised
to fix this.
Action: Mark Wahl, please fix this. ;-)
However, it was noted that ModifiersName applies to Entries,
not
attributes, so it is unclear how this specific example
applies. Summary:
doesn't affect requirements draft, but
does affect LDAPBIS.
Action: Also recommended that Mark Wahl post to the list a
set of
additional requirements on operational attributes
that must be maintained
during replication.
Inconsistent Definitions. It was pointed out by Albert that
the
definition of an updateable replica conflicts with
section 5.6.
Action: Change the definition of an updateable replica to:
"An
authoritative read-write copy of the replicated
information". The room
seemed happy with this.
Summary of issues between URP and MDCR, and resulting action
items:
1. Atomicity and related concepts
Action: Making some explicit statements
about atomicity in
the requirements document would clear up this issue.
2. modifiersName and other operational attributes
Action: this point is
moot
3. Change reports - Use ProtocolOps or Primitives
Action: no consensus,
need further discussion on the list.
It was note that we need to include how
each addresses (or
doesn't address) atomicity.
4. Eventual convergence - Version numbers or timestamps
Action: looks
like a religious argument; no consensus reached.
5. Oscillation
The claim has been made that MDCR oscillates. Everyone
agrees that oscillation is bad. Needs more discussion on the list.
6. Implementation and performance issues
Action: There have been claims
that URP and MCR have
comparable performance and implementation
requirements.
Suggest that we accept this unless someone can prove that
this is not true, and prove it quickly.
7. Revocation notices
Action: unclear. MDCR could add them, and they
aren't
applicable for URP. Suggest dropping this, there are bigger
fish
to fry.
8. Strong consistency and transactions
Action: LDAP doesn't do
transactions, so this is out of
scope. As a result of this, co-chairs will
update the
charter to note that transactions are expicitly out of scope.