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

Hi Daniel,

Daniel Pluta wrote:
> Hi Steven,
> 
> Steven Legg wrote:
>> Daniel Pluta wrote:
>>> 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. 
> 
> UTC is used.
> 
> 
>> 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.
> 
> 
>> 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) ?
> 
> There are various scenarios where this matching feature offer
> advantages in addition to the existing ones. Especially in cases 
> 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.

> 
> In environments the server does not trust the client side specified 
> time-stamps a server can use a filter based ACL statement to enforce the 
> filtering (OpenLDAP already support filters within ACLs).

The assertion here would be that it would be desirable to be able to express
access controls that depend on the relationship of timestamps in an entry
to the current time. That's something that can't be expressed otherwise.
It isn't about trusting the client's idea of UTC because that doesn't come
into the access control decision.

> 
> 
>> Do you have a specific reason why clients need to know the server's 
>> timezone ?
> 
> Some clients for example LDAP servers (thinking of global replication
> over different timezones) profit from this information:
> During replication of special/custom time-stamp attributes' values the
> time-stamps can be adapted/transformed according the timezone delta
> between source and destination.

If the special/custom time-stamp attributes use the LDAP Generalized Time
syntax, then all servers will be working in UTC and all the values
will be in UTC or have sufficient information to derive UTC. There is
no need for any server to know the timezone of any other server.

 > This ensures that the current time
> comparison delivers always the same result independent from which LDAP
> server in which timezone the client contacts. E.g. office-hours which
> are defined in the user's entry.

If the office hours attributes use the Generalized Time syntax, then
they are effectively expressed in UTC with the timezone already factored
in.

 > 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.

> 
> 
>> 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.

> - Depending on the first and the second point: What's the reason (use
> case / scenario) where these information and the possible processing
> overhead is worth for?

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.

> 
> 
>>> 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.
> 
> Please forget the additional syntaxes for now. In the meantime I've
> learned that there is no possibility to support binary searching by
> using an attribute of generalizedTime syntax within extensibleMatch
> filters because ordering rules cannot be handled in extensibleMatching
> rules because the specification does not say anything about ":<=" or ":>=".

I'm afraid you're under a misapprehension. Although the string representation
of an extensible match contains a equals sign, it is just meaningless syntactic
fluff. The extensible match applies a matching rule, which is a boolean
predicate that may or may not represent a relational operator like "=".
So that the extensible match had the same expressive power as the other
filter items, the X.500 working group defined matching rules for each of
the syntaxes that has an obvious equality or ordering relationship between
values. For each syntax with an ordering relationship they defined two
predicates; an equality or "=" matching rule (e.g., generalizedTimeMatch)
and an ordering or "<" matching rule (e.g., generalizedTimeOrderingMatch).
This is sufficient to construct the other relational operators through an
expression of extensible match filter items. That is,

     "type=value" is (type:generalizedTimeMatch:=value)
     "type<value" is (type:generalizedTimeOrdering:=value)
     "type<=value" is (|(type:generalizedTimeMatch:=value)(type:generalizedTimeOrdering:=value))
     "type>value" is (!(|(type:generalizedTimeMatch:=value)(type:generalizedTimeOrdering:=value)))
     "type>=value" is (!(type:generalizedTimeOrdering:=value))

There is nothing magic about the choice of "=" and "<". The X.500 working
group could have chosen any other pair of the relational operators, or more
than two, but this is the convention that has been followed since. Therein
also lies the reason why I suggested that currentTimeMatch and
currentTimeOrderingMatch were sufficient. It's not wrong to define more
rules as you have done, just unconventional and excess to requirements.

So it is possible to perform binary search on a syntax using extensible match
given an ordering matching rule for that syntax, and it is meaningless to talk
about ":<=" or ":>=" with respect to the extensible match filter item.

> 
> <off topic>
> Please correct me if I'm wrong but I currently do not understand exactly
> what's the reason ":<=" or ":>=" is not supported/specified for
> extensibleMatch filter expressions? Is it because of an LDAP
> technical/design intention or just a specification issue?
> Is it fallacious that in some time in the future the extensibleMatch 
> filter specification may be gets extended to support ordering matching 
> e.g. by ":<=" and ":>="? If an extension is possible then the additional 
> syntaxes will be of use. In the meantime just ignore them please.
> </off topic>
> 
> Independent of the syntax and extensibleMatch filter expression question 
> we are nevertheless still focusing on enhanced privacy requirements and 
> solutions by using the matching rules. The four matching rules 
> (nowOrEarlier|nowOrEarlierOffset and nowOrLater|nowOrLaterOffset) in 
> combination with OpenLDAP's powerful ACL definitions do already support 
> to hide entries very easy and flexible without major source code 
> changes. The same should be true for any other LDAP server that offers 
> support for filter statements within ACLs.
> 
> 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). 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.

> 
> 
>> 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.

> 
> 
>>> 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 :-).

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@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
>>
> 
> 