ldapext@ietf.org
[Top] [All Lists]

Re: [ldapext] [Fwd: New Version Notification for draft-pluta-ldap-srv-si

Subject: Re: [ldapext] [Fwd: New Version Notification for draft-pluta-ldap-srv-side-current-time-match-00]
From: Steven Legg
Date: Tue, 20 Apr 2010 12:45:31 +1000

Hi Daniel,

Daniel Pluta wrote:
Dear Steven,

many thanks for your feedback! Your suggestion regarding a solution to support "entry validity period evaluation" based on simple server internal time-stamp delta calculations which result in a derived boolean attribute sounds interesting and is surely worth to be discussed in detail in the (near) future, but... ;-)

Our primary intention of this draft is to introduce some kind of additional not yet available matching possibilities for LDAP: we need to implement support for comparison of time-stamp values relative to the server's current time and some related requirements, publishing the current time and timezone (location) information via the Root-DSE.

GeneralizedTime values in LDAP are required to be in UTC or in local time
plus timezone (from which UTC can be calculated). The time matching rules
compare values according to their corresponding times in UTC. In reading
your draft I assumed that your time matching rules also operate with respect
to UTC. If that is not the case, then some clarification is needed. If it
is the case, then it boils down to a question of whether a time comparison
involving the current time is performed using the client's idea of UTC or
the server's. In an ideal world the client and server clocks will be
perfectly synchronized. In practice they will still be fairly close. Do
you have a use case where it is important to be using the server's idea
of the current time (which justifies new matching capabilities) rather
than the client's (which is achieved with current matching capabilities) ?
Do you have a specific reason why clients need to know the server's timezone ?

Incidentally, I have implemented operational attributes that expose the
current date and time, current time of day and current day of the week.
They appear in every entry and are created on demand.


Our finally mentioned use case/scenario which combines the matching rules with further syntax and schema definition to achieve some kind of "entry validity period evaluation" feature is intended as example to motivate the need for current time matching.

I don't think it helps. Rather, it raises new issues (like questions
about appropriateness) and the need for further justification. If particular
privacy outcomes are not a goal, then all you need is two matching rules
with DURATION assertion syntax that I might call currentTimeMatch and
currentTimeOrderingMatch. The currentTimeMatch rule tests if an attribute
value is equal to the current time plus an offset (i.e., the DURATION
assertion value, which can be positive, negative or zero) and the
currentTimeOrderingMatch tests if an attribute value is less than the
current time plus an offset.

> It is a direct result based
on our experiments with current time matching rules, which probably deflects from our primary intention.

Your suggested solution does not need to make use of current time matching rules (due to server internal delta calculation which first of all seems to be an easy and elegant way) so this solution is strictly limited to the scenario where two time-stamps define a rather hard validity period (begin and end). On the other side, what about the possibility to use one of the two time-stamps (or any other time-stamp attribute) within scenarios where flexible transitions times (e.g. +2 months/days/... after or before a given time) need to be supported, too? Therefore the server internal calculation suggested by you need to be customizable depending on the operations details...

Yes, that's why I said "it becomes a question of how expressive should
the derivation rules be and what form should they take ?". One way to
express the derivation rule for a boolean attribute is as a search filter,
which could use currentTimeMatch and currentTimeOrderingMatch ! It may
be more appropriate to have different derived attributes and end-points
to reflect "soft" and "hard" validity. Detailed use cases would help
guide such decisions. However, it doesn't matter if privacy outcomes
are not the goal.


To support these kind of requirements the matching rules are of general interest. Based on our current experimental implementation (which possibly needs to be reduced to the matching basics) of these matching rules in combination with your implementation of the X680 duration specification the matching could be of general use for LDAP, too.

In our opinion there is currently nothing to be said against the reasonable use of both mechanisms. What do you think about this?

New matching rules and derived attributes both have their uses,
singly or in combination, but using syntaxes to achieve access control
is just wrong to my mind.

Regards,
Steven


Best Regards,
Daniel


Steven Legg wrote:

Hi Daniel,

Daniel Pluta wrote:
Dear ldapext,

we would appreciate your valuable comments and feedback regrading our draft specifying "ldap server side current time matching".

The draft is essentially about enforcing access control policy through
schema mechanisms, which strikes me as inappropriate for two principal
reasons:

(1) Schema is supposed to be immutable, whereas access control policy
is subject to change. If access control policy is reflected in the
attribute syntaxes one chooses, then that policy is permanently locked-in.

(2) Schema is one-size-fits-all. The same rules apply to everyone,
regardless of whether they are anonymous guest users or highly privileged
administrators. Access control policy is rarely that uniform.

Privacy goals should be addressed through access control mechanisms,
but of course you are hampered by the absence of a common, standardized
access control mechanism across all LDAP implementations. With that in
mind I would take a somewhat different approach to a solution.

Basically you want to allow general access to a derived property of
a collection of attributes while simultaneously enforcing restricted
access to that collection of attributes. What I would do is define a
schema mechanism for defining derived attributes, i.e., attributes
whose values are algorithmically derived by the server from the values
of other attributes in the same entry. The derived attributes can then
be subject to different access controls than the source attributes.

In your example with the notValidBefore and notValidAfter attributes,
I imagine having a derived attribute called currentlyValid, with
Boolean Syntax, that is derived from notValidBefore and
notValidAfter according to the following pseudo code:

    if (current time >= notValidBefore and
        current time <= notValidAfter) then
        value = TRUE
    else
        value = FALSE

Privileged users and processes would be given permission to read
and update the notValidBefore and notValidAfter attributes, but
regular users would only be able to read the currentlyValid
attribute. This kind of access control policy can be expressed in
existing LDAP access control schemes even though they differ between
implementations.

That takes care of the nowBefore and nowAfter syntaxes. I don't see
that you achieve anything with the nowBeforeOffset and nowAfterOffset
syntaxes since a user can just use a binary search to determine the
actual values of the target attributes by adjusting the offsets (a
client can guess the time at the server with reasonable accuracy).
Limiting the sign or magnitude of the offset would provide partial
protection, but a derived attribute could also do that. For example,
to allow regular users to determine when a valid account became valid
but not allow them to determine whether or when an account will become
valid at some time in the future I would define a derived attribute
of GeneralizedTime syntax whose values are determined by the following
pseudo code:

    if (current time >= notValidBefore)
        value = notValidBefore
    else
        absent

It becomes a question of how expressive should the derivation rules be
and what form should they take ? I think OpenLDAP might have some
capabilities in that area already.

The nowOffset syntax isn't required if derived attributes are used instead, but if you want to persist with it I suggest you align it with the existing ASN.1 DURATION data type (see http://www.itu.int/rec/T-REC-X.680-200606-S!Amd3/en ) rather than rolling your own format, not the least because I already have an implementation that supports DURATION as an attribute and assertion syntax
for both X.500 and LDAP.

Regards,
Steven


Please see below for the abstract.

The full version can be found here: http://www.ietf.org/id/draft-pluta-ldap-srv-side-current-time-match-00.txt

Many thanks in advance!

Best regards
Daniel


-------- Original-Nachricht --------
Betreff: New Version Notification for draft-pluta-ldap-srv-side-current-time-match-00
Datum: Thu, 25 Mar 2010 15:51:33 -0700 (PDT)
Von: IETF I-D Submission Tool <idsubmission@xxxxxxxx>


A new version of I-D, draft-pluta-ldap-srv-side-current-time-match-00.txt has been successfully submitted and posted to the IETF repository.

Filename:     draft-pluta-ldap-srv-side-current-time-match
Revision:     00
Title: Lightweight Directory Access Protocol (LDAP): Server Side Current Time Matching - Matching Rules and Syntaxes
Creation_date:     2010-03-25
WG ID:         Independent Submission
Number_of_pages: 20

Abstract:
This document extends the Lightweight Directory Access Protocol
(LDAP) to support server side current time matching.  Matching of
attribute values against an LDAP server's current time offers
additional functionality with regard to authorization and fulfills
enhanced data privacy requirements for restrictive environments.
Therefore this specification defines four additional syntaxes and
related matching rules useful for extensible matching in association
with these syntaxes.  In addition and for general use the matching
rules defined in this document are also applicable to any attribute
type definitions that are using the 'Generalized Time' syntax.  This
specification also contains restrictive attribute type definitions
demonstrating the usage of the introduced syntaxes and matching
rules.




The IETF Secretariat.
_______________________________________________
Ldapext mailing list
Ldapext@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ldapext

<Prev in Thread] Current Thread [Next in Thread>