[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
draft minutes of April meeting
Here are the minutes I took for this meeting. Sorry for the delay in posting
them to the list.
Draft minutes for the LDAPEXT Working Group meeting at Spring 1998 IETF
LDAPEXT met in three sessions on April 1st, 1998.
First Session
1. Agenda Review
Several additional topics were added to the agenda: Start TLS and
recommended authentication methods, security parameters for signed
operations, transactions, schema constraints and referrals.
A request to discuss NIS integration was referred to the LSD working
group.
2. Status Update
The draft describing extensions for dynamic entries has completed
WG last call and has been sent to Harald Alvestrand.
ACTION (Mark Wahl and Tim Howes): send draft on caching, which has completed
last call, to Harald.
ACTION (Mark Wahl): revise draft on language tags and send to Harald.
Concensus was not reached on the simple paged draft as a standards
track document. The WG chairs and area directors will discuss with
the authors of that document whether it should be published as
an informational document.
There were significant comments on the referral draft during its
last call period.
ACTION (Mark Wahl and Tim Howes): revise the referral draft and
issue last call again.
However, the area directors will not publish these extension documents
until the recommended authentication methods document has been published.
3. Start TLS and Recommended Authentication Methods
3.1. Preventing man-in-the-middle attacks
An issue was discussed on the mailing list regarding whether client
implementations are required to check that the server to whom they have
established a TLS connection is identified as the subject of the server's
certificate. This depends on the representation of the server's DNS
name in the certificate. It was suggested that there needs to be either
text in the security considerations section, or the client behavior must
be documented. The client behavior text would depend on the TLS WG, since
it affects all application protocols using TLS.
ACTION (Jeff Hodges): send suggested text to the security area for review,
then submit revised Start TLS draft.
3.2. Format of authorization identifiers
The second issue was whether authorization ids used in the SASL credentials
field must be Distinguished Names or not. A Distinguished Name is
syntatically unambiguous, however some simple clients may not know their
own Distinguished Name and would want to use a more basic username. The
SASL RFC requires that the protocol, in this case LDAPv3, define precisely
the form of this ID, however this has not been done in RFC 2251, and so
the issue has arised in the recommended authentication methods document.
It was noted by Paul Leach that the binding between the authorization id
and the user is not necessarily authenticated. Also it was noted that
if a DN is not used, then the mapping of a username to a DN needs to be
algorithmically represented so that it can be replicated between servers.
A resolution was reached in the third session, following a BOF
between Mark Wahl, Bob Morgan, John Meyers.
ACTION (Mark Wahl): produce new authentication methods draft, then go to
last call.
4. Sorting
Chris Weider described the changes discussed on the mailing list. These
were to clarify the handling of entries which lack the attributes being
used for sorting, and to note that sorting is not done across servers
where there are referrals.
ACTION (Chris Weider): reissue draft with these changes, then the WG will go
to last call.
5. Access Control Requirements
Ellen Stokes summarized the open issues with the document. These are
primarily whether there could be explicit denials, and nested groups.
The draft currently suggests both should be not-recommended.
5.1. Nested Groups
Richard Huber noted that nesting is useful to prevent a proliferation
of groups. However, with nesting there can be side effects not known
to the administrator of one group if a group under another administrator's
control is modified. Jeff Hodges suggested it was the responsibility of
the deployers to ensure that consistency was maintained, rather than the
responsbility of the specification to prevent it from occuring.
5.2. Explicit Denials
Paul Leach raised the issue from the WEBDAV working group, that it is
hard to disallow access if there are multiple access protocols as there
is no common ACL format.
Richard Huber also suggested that with inherited access control it is
more necesary to have negative rights.
Tim Howes and Bob Blakely polled the meeting and determined there was
rough consensus on this topic.
ACTION (Bob Blakely) revise the document to allow explicit denials.
6. Access Control Model
Deborah Byrne described their proposed access control model, for which
a draft had recently been sent to the list. Each access control subject
has security attributes which describe the permitted actions. Attributes
are grouped into classes by sensitivity. Inheritance would be used to
eliminate the need to store access control information with every entry.
7. LDAP Signed Operations
Pat Richard listed his planned changes to the LDAP Signed Operations
document. This would be to include a reference to PKCS #7 for the
definition of the LDAP signature, and make the signature structure more
extensible. There was also inteerest in merging with the draft from
Vesna Hassler.
ACTION (Pat Richard): produce updated draft.
8. Persistent and Triggered Search
There are still two proposals for client notification of search changes,
however the proposals have slightly different properties and each is
suited for particular ranges of applications.
Russell Weiser pointed out that the documents require more work in the
security considerations sections, and Harald Alvestrand reminded the authors
to be sure to discuss the implications on scaling as the number of users and
the number of updates increases.
ACTION (Mark Wahl and Mark Smith): revise both documents and reissue.
9. Scrolling
David Boreham described the current state of the virtual list view draft.
The document currently requires that sorting also be used simultaneously,
and there have been some comments on this as the simple paging draft did
not require sorting.
ACTION (David Boreham): revise draft and reissue.
10. C API
Mark Smith listed the minor issues which still need to be done: changes to
data type definitions, cleanup of the language regarding when information
should be freed, and integrate comments from Mark Wahl relating to the
functions added in the latest revision.
There is a new function for determining the version of the protocol
supported by the C API, and Mark Wahl suggested that this should also be
extended to support the detection of API capabilities as there is a
proliferation of extension API documents.
ACTION (Mark Smith): revise draft and reissue.
11. Transactions
A document was recently published on adding transaction operations to LDAPv3.
There are still some open issues, such as time limits on transactions, whether
neested transactions and operations across referrals are supported, and the
interactions with other protocol extensions.
There was no consenus on whether this should be added to the charter.
End of First Session
Second Session
12. Access Control
12.1 Prescriptive ACLs
Helmut Volpers asked about the capability of defining prescriptive ACI for
covering a whole subtree of entries. Bob Blakely suggested this would be
done through inheritance, however inheritance is not yet defined for LDAP.
It may be desirable to allow Prescriptive ACIs to cross server naming
context boundaries, therefore the mechanism would need to be defined in
LDAP how changes to one server are reflected to subordinate servers.
12.2. Relationship to X.500
There were questions why the access control format and model defined in
X.500(1993) was not used. There was interest in investigating a subset of
the X.500 model for use in LDAP.
ACTION (Ellen Stokes): document an analysis of the relationship to X.500(93)
access control
12.3. Nested Groups and Explicit Denial
Since these topics were discussed earlier, there was a meta-discussion on
whether there should be optional or extensible elements in the access
control specification. If so, how are these handled when there is
replication?
12.4. Subject Expressability
It is desirable to be able to express in the model certain subjects, such
as "self" or "everyone".
12.5. Default ACL Policy
The proposal had appeared to describe the default access control policy as
granting read access to everyone, and Ed Reed and others had suggested that
the default should be changed to granting no access. In their proposal,
the default access control policy for attributes could be changed by the
administrator.
12.6. Multiple ACL Formats
Two related topics were discussed: whether there should be a mandatory to
implement access control mechanism for LDAP, and more generally, whether
access control in IETF application area protocols should be defined in terms
of policy on the objects accessed or policy on the protocol.
ACTION (Tim Howes): ask for input from the security Area Director.
End of Session
Third Session
13. Authorization ID Format
The third session presented a proposed resolution to the representation
of authorization identifiers in SASL credentials. In the revised document,
the authorization id should be a choice of "dn:" followed by a DN,
"u:" for user followed by a UTF-8 encoded username, or a zero length string.
There may be more discussion on the list on the related topics of
replicating mappings for usernames to DNs, and on server proxying.
End of Third Session
Mark Wahl, Directory Product Architect
Innosoft International Inc. / Critical Angle Inc.