Re: [ldapext] [Fwd: New Version Notification for draft-pluta-ldap-srv-side-current-time-match-00]

Hi Steven,

Steven Legg wrote:
> Daniel Pluta wrote:
>> Steven Legg wrote:
>>> Daniel Pluta wrote:
>>> 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.
>> 
>> We specifically require the server's idea of UTC.

And you are right, the timezone information in the Root-DSE is not
needed for our mentioned replication scenario in case every time-stamp 
value and the comparison is strictly made using UTC.

At first I've been thinking of using localtime which:
- would justify the transformation but causes major disadvantages at
least in complexity, usability, replication and in other cases e.g. when 
taking a replica's dump to recover the master or another replica in 
other timezones.
- is against common accepted LDAP specifications (everything is UTC)
- should no longer be thought about

Nevertheless we are currently still think that the timezone information
should be published:
- this data "completes" the current time information
- this information can be used to derive a server's timezone position
(at least as long as there is no specification how to publish the global
positioning system information)

>> configuration directives in third party products do not allow to be
>>  dynamically rewritten to use the client's current time for each 
>> request. Specifying a search filter 
>> (endOfLifeTimeStamp:noOrEarlierMatch:=NOW) solves this. A client
>> does not need to replace the assertion value for each request any
>> more.
> 
> I think this is reasonable justification for new matching rules.
> 

Fine, thanks.

>> The comparison result need to be independent of the replica (its
>> timezone) a client connects to.
> 
> It should be already because all comparisons are according to UTC.

As already said above: that's right.

>>> 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.
>> 
>> Ok. We have decided to take the Root-DSE because we are not sure 
>> whether this information is needed for each entry: - As time flows
>> which time of day is it? The time of the operation's request or the
>> time of the result set's delivery (constant result set delivery
>> time or still "drifting" for each result set's entry's delivery)?
> 
> Currently (for convenience) it is the instant when the entry contents
> are composed for final filtering and access control checks. This
> means that each entry could have a slightly different time. This is
> adequate for our current purposes because the time difference between
> the first and last entry is small compared to the precision that the
> consuming applications actually need, and small compared to the
> typical skew between different machines. If that ever changes we will
> review how the timestamps are generated.
> 
>> - Depending on the first point: how does this impact perfomance?
> 
> Barely at all in the great scheme of things. The attributes are only
>  generated if they are specifically requested or required.
>> case / scenario) where these information and the possible
>> processing overhead is worth for?
> - Depending on the first and the second point: What's the reason (use
> 
> 
> The primary motivation was to allow access controls to be set up
> based on time of day. The eB2Bcom directory also allows access
> controls to be specified using filters. With these operational
> attributes we can do things like permit access if:
> 
> (&(currentTimeOfDay>=09:00:00+10:00)(currentTimeOfDay<=17:00:00+10:00)).
>  N.B., the syntax of currentTimeOfDay uses a constrained ASN.1 TIME
> type.

Ah I see, this is exactly the opposite approach of ours - but an 
interesting solution at least for this specialized scenario (and limited 
for a short period of time e.g. a day).

Therefore in our opinion it's not comparable to the draft's matching 
rule approach and rises the following questions (if nevertheless compared):
- the many time determination operations for huge result sets (which can 
be optimized)
- the client side specified filter criteria

The first point can be easily optimized:
In huge result sets the repeating time determination for each
entry does possibly take some time. I would suggest to use an
instantaneous and constant time of the request/operation/etc even
because you already said, that the time deltas are just slightly
different and are to small to be of any great effect (so, why spending
processing time for them?).

Comment regarding the second point:
Instead of using calculated times, when using in backend stored
time-stamp values in combination with our matching rule each entry can
have different period limiting time-stamp pairs. This is an important
difference regarding the use in automatic provisioning scenarios where 
we want to support selection of all currently valid entries (independent 
from the distinct time-stamps, which should not be readable or even 
binary search able) in contrast to your scenario.

Our approach handles huge and tiny result sets using the same matching 
rule mechanisms independent from operating as single userDN (self) or a 
service's DN.

However, I think I understand your scenario and idea. In
regard to "currentTimeOfDay" this seems to be a fine solution in case
your clients and services are trustworthy enough to be allowed to 
define/request the periods on their own. Regardless from our concerns, 
your currentTimeOfDay syntax is very interesting, to extend our matching 
rules to also match these kind of values, too.

Instead of publishing the current time in each entry our approach allows 
us to uses a single, centralized place in the DIT (e.g. Root-DSE) to 
publish the server's current time information. The time information is 
only used seldom in combination with our matching rule approach but is 
useful to offer clients a general chance to determine the server's 
current system time. When using tls/ssl in general the server's system 
time should be ok, but nobody knows. So the clients needs a
chance to query the server (using LDAP) for its current time at least in 
UTC.

Although a concrete scenario where the timezone is needed is currently 
missing, additionally publishing the timezone (in contrast to our draft 
e.g. in an extra attribute) makes this kind of information (the time) 
more complete, at least in our opinion.

>> In addition to privacy another scenario where the server side time 
>> matching is very useful affects provisioning systems. E.g. identity
>>  management (IDM) system infrastructures can profit from such
>> matching rules. They can be pre-provisioned (pre means timely in
>> advance) and entries become available just-in-time (based on a
>> single time-stamp attribute for example), without the need for an
>> external event that has to trigger the provisioning (results in an
>> entry's visibility). Beside the initial provisioning, the
>> provisioning life-cycle becomes independent, more flexible, gets
>> simplified and can be consolidated into the ldap server itself. Not
>> to mention automatic de-provisioning without manual/external
>> just-in-time interventions. De-provisioning is highly probable the
>> wrong expression: In IDM systems former identities need to be
>> removed from core services but often also need to stay available
>> for a subset of services (for alumna). Currently this is often
>> controlled by complete entry provisioning or simple attribute
>> changes (event or timely triggered or both). Although these changes
>> are known in advance for the majority of the users, complex
>> interdependent event handling mechanisms and triggers are 
>> externally implemented to manipulate (e.g. hide or disable) entries
>>  for distinct services... When using current time matching no
>> events are needed in those scenarios. In OpenLDAP for example, by
>> using an appropriate ACL the event's can be planned in advance and
>> the partial de-provisioning will automatically and immediately take
>> effect when time has come.
> 
> I can see how that works if the services always bind to the directory
>  and perform operations as themselves but it wouldn't work if the
> services proxy the end user or proxy other services. In all, this
> feels like a workaround for simple-minded services that assume the
> service is available to a user just because the user has an entry.
> The ideal solution would be for the service to check that the current
> time is in the validity period for that service and user (in which 
> case the service's idea of UTC is just as good as the LDAP server's).
> 

In our current scenario service proxies are supported as well. They
could also contain time-stamp attributes that are used to determine
whether a service is currently allowed to operate on the directory 
(please see below for details).

> Where there is some limited ability to configure the service with
> fixed LDAP searches then the new matching rules become useful. If
> that isn't an option, then the new matching rules could be used to
> limit the visibility of the user's entry for different services. Bad
> luck if the services proxy other identities.

Probably I cannot follow you in detail. Could you please give me a more 
detailed example? Thanks a lot.

>>> 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.
>> 
>> As explained above LDAP servers that support filter statements
>> during ACL processing can fulfill the privacy goals very easily,
>> because the matching rules can be used to server-side force a
>> filter via ACLs that clients cannot overwrite or bypass.
> 
> 
> In that case you don't need extra syntaxes or all four matching
> rules.

Indeed we need the syntaxes to prevent services to be able to determine
the limiting time-stamp values for example of an user's entry which has 
to be searched by a service before it can be used for authentication via 
a bind operation. We are yet already able to prevent inquisitive 
services to get more information than that are needed just in the moment.

BTW: I could not find an RFC which explicitly says something
about how ordering matching rules may/must/should be supported/processed
in extensible match filters. On the other hand I also have not found a
statement that ordering matching rules should not be supported in
extensible match filters...
Although, OpenLDAP currently does not support ordering matching rules in
extensible match filters it's possibly just a question of time when this
"feature" becomes supported, too (in case the/a specification says so?).
On the other hand, other directory server implementations may be already
support ordering matching rules in extensible match filters (the way
you've explained above) and probably also want to prevent client's to 
determine the exact time-stamps vaules - just by using the new syntaxes 
which we derived from gerneralizedTime.

Now let me please come back to explain the common need for the two extra 
syntaxes (named "nowBefore" and "nowAfter") mentioned in our draft:

Imagine two period limiting time-stamp attributes' values. These
attributes need to be searchable to allow an ACL engine (that supports 
searchfilter) to process the filter statement in the context of the user 
or the context of a service's bindDN. So at least search (ideally 
without read) permission has to be given to self, the service's bindDN 
or both. Search permission for "self" is not as critical as search 
access for the service's bindDN. Snoopy bindDN owners could try to 
gather more detailed information from exntries than originally intended 
(e.g. looking into the future or past using binary search...)

Thus, search access currently cannot be further limited e.g. to 
"generalizedTimeMatch-only" and there's currently no easy or general 
(even standardized) way to handle/extend ACL processing to exclude 
distinct matching rules from search (matching) operations, using 
generalizedTime syntax for the two limiting attributes leads to the 
binary search problem in case ordering matching rules are usable in 
combination with extensible match filters.

By using our two syntaxes, services' bindDNs are able to use the 
time-stamp limits (using our matching rule) right in the moment but they 
are not able to determine any entry's distinct time-stamps (even not 
their own where this is appropriate).

Additionally both attribute value syntaxes are not completely new. They 
are just syntactically derived from generalizedTime syntax. Both are 
explicitly not associated with the generalizedTimeOrdering matching rule 
to prevent binary searching in extensible match filters. In our opinion 
the above mentioned limitation (in regard to privacy protection against 
binary search) justifies their introduction. How these syntaxes are used 
in an userApplication schema or even product specific ACL definition 
(where supported) should of course be left open to the directory 
designers and administrators.

Appendix:
Of course you are right, the other two extra offset-syntaxes (defined in
our draft) are only nice to have but not needed (in regard to privacy) 
because clients can of course specify all kind of offsets to do a binary 
search. Therefore these syntaxes can be removed from the document. 
generalizedTime syntax is completely sufficient in regard to 
Offset/Duration matching.

>>>> 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,
>> 
>> yes, for sure.
>> 
>>> but using syntaxes to achieve access control is just wrong to my
>>> mind.
>> 
>> yes, at least as long as extensibleMatch filter expression do not 
>> support ":<=" or ":>=" comparison operations...
> 
> ... which they do and always have :-).

Hmmm, please let me cite BOFH chap. 13: "Yes means No and No means Yes.
Delete all files [Y]?" ;-)

Based on your clarification regarding the possibility to use ordering 
matching rules in extensible match filters our previous position 
regarding the sabove "yes, at least as..." has spontaneously changed 
into the opposite. As explained above we would like to see the 
additional two syntaxes to solve possible privacy concerns (regardless 
of distinct products' ACL processing features), so please let me answer 
your previous statement once again:

> but using syntaxes to achieve access control is just wrong to my
> mind.

Achieving additional access control features is just a side effect 
(which affect varies between different directory server products' features).
The additional syntaxes' limitations are useful in common
privacy related scenarios where time-stamp derived attributes should by 
design only be search able using our matching rules. Preventing snoopy 
service's (proxy?) bindDNs to get more information about an entry than 
actually is needed.

Best regards,
Daniel

> Regards, Steven
> 
>> 
>> Best regards, Daniel
>> 
>> 
>>>> Steven Legg wrote:
>>>>> 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@ietf.org>
>>>>>> 
>>>>>> 
>>>>>> 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@ietf.org 
>>>>>> https://www.ietf.org/mailman/listinfo/ldapext