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

[Steven Legg <[e-mail]>]

Hi Daniel,

Daniel Pluta wrote:
> Hi Steven,
> 
> Steven Legg wrote:
>> Hi Daniel, Daniel Pluta wrote:
>>> Hi Steven, Steven Legg wrote:
>>>> Daniel Pluta wrote:
>>>>> Steven Legg wrote:
>>>>>> Daniel Pluta wrote:

[snip]

>>> 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.
>>
>> The pertinent question is: why? The IESG will probably want to know.
> 
> In our opinion and based on our approach the question "Why?" does not
> exist. The only open questions would be "where and how?". Please let me
> try to explain from the beginning:
> 
> Q: Why should the server publish its time in general?
> A: The answer is related to the big picture behind our scenario where
> both, syntaxes and matching rules are in operation.
> The matching rule operates on the server side. The clients do not need
> to use a distinct time for example using time-similar assertion values
> in filters strings. Clients just use "NOW" as assertion value which the
> server internally expands into its current server side time. Based on
> this internal (hidden) expansion the client can only *hope* the server
> delivers the currently available entries.
> Q: But why the client's only can hope?
> A: Depending on the scenario which leads to different data-privacy
> requirements the clients are not always able to verify the returned
> entries time-stamps because permission to access the result set entries'
> time-stamp values (in case our specialized syntaxes are in use) by read
> may be knowingly (a directory operator'/designer'/administrator's
> decision) denied. To give interested clients a chance to determine the
> server's time we suggest that the server should publish its current time
> to be query able for some kind of verification / debugging possibility.

The immediately preceding sentence is the answer to the "why?"; so that
clients can verify that the server's idea of "now" is reasonable, or to
debug unexpected results.

> 
> Let me now come to the still somewhat open question: "Where and how?"
> Q: Where should the time be published? Why within the Root-DSE, and not
> in each entry?
> A: In our opinion clients would ask servers seldom for their current
> time but there exist some justifications for clients to do so. The time
> information is very helpful especially in case of supposed errors or for
> debugging. Imagine replicated environments where one replica system for
> example is operating using the wrong system time. This would probably
> lead to strongly varying result sets depending on the server that
> answers the queries.
> Because the time is so seldom queried we prefer its publication within
> the "neutral zone" the Root-DSE, instead of attaching it using an extra
> attribute for each entry.

You haven't considered that the LDAP server a client is connected to could be
an X.500 server supporting a distributed DIT, or a virtual directory. In both
cases the result returned to the client can contain entries contributed by
more than one server, each of which has its own time. The time reported
by the server the client is directly connected to may be representative of
all, some or even none of the entries in the result. Publishing the time in
each entry means that each entry in the combined result indicates the
particular value of "now" against which it was evaluated.

> 
> And finally the minor important question:
> Q: In case the server would already publish its current system time,
> what about additionally publishing the server's timezone?

Publishing the server time as local time plus time zone (which is allowed
by the Generalized Time syntax) allows UTC, server local time or time zone
to be recovered from the one value. I would recommend doing that.

> A: We currently do not have an idea why and for what reason to insist of 
> publishing the timezone. The only reason is: a timezone generally 
> somehow belongs/completes an information about the time (regardless 
> whether LDAP internally always uses 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.
>>
>> My opinion is different. An operational attribute to publish the
>> server's time and/or timezone isn't significant to the remainder of
>> the draft and could just as well be in a separate draft, or not
>> mentioned at all. So I don't see it as being desirable for reasons of
>> completeness.
> 
> Please see above: time is a must-have, timezone is just nice to have

Fair enough.

> 
> 
>>>>> 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.
>>
>> In the ideal situation the "foobar" service would test whether it is 
>> currently enabled for a given user by searching the user's entry with
>> a filter like:
>>
>>
>> (&(foobarStartTime<=20100423133800+1000)(foobarEndTime>=20100423133800+1000)) 
>>
>>
>>
>>
>> where (for example) the current time is 20100423133800+1000 as far as
>>  the foobar service is concerned.
>>
>> If the foobar service can only be configured with a fixed LDAP
>> filter, then that filter would need to be something like this:
>>
>> (&(|(foobarStartTime:currentTimeMatch:=P0S) 
>> (foobarStartTime:currentTimeOrderingMatch:=P0S)) 
>> (!(foobarEndTime:currentTimeOrderingMatch:=P0S)))
>>
>> Note that "P0S" is a duration of zero seconds.
>>
>> If the foobar service just assumes that it is enabled for any user
>> whose entry is visible, then there would need to be an access control
>> in the LDAP server that only allows the foobar service identity to
>> see a user entry if the preceding filter applied to that user entry
>> is satisfied.
>>
>> If the foobar service used the user identity rather than its own to 
>> determine the existence of the user entry, then there would need to
>> be an access control in the LDAP server that only allows the user
>> identity to see its own entry if the preceding filter is satisfied.
>> However, it then isn't possible to have separate start and end times
>> for each service. There would be one start time and end time that
>> applies to all services and the user would not even see their own
>> entry outside those times.
> 
> This is all fine, at least in case you trust the services. Don't call us 
> paranoid, but in our scenario we even do not trust the (even internal) 
> services, at least in regard to data privacy concerns. Of course we do 
> trust our services regarding their core competence: offering the maximum 
> service quality.
> 
> Imagine huge organizations where service administrators can very easily 
> and lucratively misuse identity information (e.g. contacting the press, 
> the business rival, or sell/buy some own/rival shares).
> 
> Please see below for one sample scenario's details and the resulting 
> requirements.
> 
> 
>>>>>> 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.
>>
>> I'm not convinced that preventing services from seeing data that are
>>  pertinent to the operation of that service is an important goal.
> 
> We are focusing on the optimization of provision process event-handling
> related questions, rather than administration and authorization 
> requirements. If our syntaxes and matching rules in general (as a 
> side-effect) also offer some management advantages in direction to 
> administration and authorization that's of course fine, too.
> 
> Two important and commonly accepted data privacy requirements are:
> - Data minimization
> - Data avoidance
> 
> In our opinion it's better to centralize (even critical) data as much as
> possible instead of distributing these critical data from one system to
> another and slightly loosing control. But this in general is an 
> architectural/infrastructure question and a discussion topic not related 
> to but taken as basis for this draft.
> 
> Imagine a new employee who has successfully applied for a timely limited
> contract. The contract says the employee should begin in 2 months and 
> the employment should end in 14 months. Why waiting for an external 
> event which triggers the provisioning (aka partially giving up control 
> and spreading sensitive data into remote systems - "data graves") in 
> exactly two month,  not later not earlier?
> 
> In our scenario a new employee has already provisioned herself e.g. by
> self-registration in the career portal (e.g. unprivileged role
> "guest" or "applicant"). A contract is usually signed some time in
> advance. Right after signing the contract the new employee's dataset is
> enriched by HR using the verified data from the CV and some more details
> from the distinct contract (e.g. the contract's time-stamps).
> As soon as the contract has been signed the new (in this moment future) 
> employee often needs instant access to the organization's (internal) 
> privileged career portal services to complete some open formalities. The 
> HR's LDAP service proxy is allowed to access these entries even before 
> the employment gets actually an active member of the organization's 
> workforce.
> 
> Two months later the entry becomes (automatically without any event)
> accessible for other system's service proxies, too - completely without
> the need of external event triggering frameworks that need to manipulate
> attribute values, move entries and the like.
> In between the successful application and the first working day it is 
> very important to strictly deny access to employees' data which for good 
> reasons are already provisioned but shouldn't generally be usable in 
> advance. Not only the user's access to a service has to be denied (to 
> avoid misuse by the user from the administration/authorization point of 
> view), but also the service must not be permitted to access the future 
> employees data (misuse, e.g. insider trading, bullying). That's the 
> reason we want to deny read access to the time-stamps at all. Services 
> shouldn't be able to notice such entries' existence

The new syntaxes are not relevant when it comes to hiding the existence
of an entry. You can do that with just the new matching rules and the
existing Generalized Time syntax. If an entry isn't visible, then
neither are its timestamps so their syntax doesn't matter.

 > and they also
> shouldn't be able to determine (binary search) the time-stamps of 
> existing entries.
> Just for fun, imagine the entry of the new head of the research in the 
> chip industry, head of design in automotive industry or head of the 
> brokerage department in the finance industry whose employment will 
> probably begin in 3 to 6 month. All these information are very sensitive
> (for both sides, the user and the organization) and need to be
> protected because they are potentially also very lucrative and thus an 
> important cause for potential internal misuse through service 
> administrators.
> 
> Sensitive for the user means (affects her new and old employment), e.g.:
> - possibly she still has a current employment elsewhere which could be
> affected negatively for her (or for the new organization in case the old 
> organization "spontaneously" rises her salary...)
> - some other user's contract will end in 2 month which unnecessarily 
> causes rumors
> - ...
> 
> Sensitive for the (new) organization, e.g.:
> - current head of department X soon joins, get's replaced or will leave 
> the organization (just imagine the value/impact of this pre-information 
> if Steve J., Bill G. or Steven B. are affected - OMG).
> - ...
> 
> For that reason no service (only exceptional trustworthy services like
> HR or equivalent) should be allowed to query a distinct object for its 
> begin and end of life time-stamp. Additionally a look into the past as 
> well as into the future has to be prohibited, too.
> 
> Because an user's information is usually needed in advance (e.g. HR
> portal self-service right after the contract has been signed) the 
> identity data regardlessly has to be existent in the system. The same 
> applies regarding the end of life: User accounts do not need to and in 
> practice they usually aren't be (completely) removed because they need 
> to remain existent for alumna services (for example a retired employment 
> still needs access to the organization's services x and a borrowed 
> employee want stay a customer or wants to get employed again next year 
> etc.pp).
> 
> That's the reason we would like to see our two dedicated syntaxes 
> specified. Beside the above sample demonstration employment life-cycle 
> scenario the draft's principal is of broader general use. Imagine 
> entries that represent permissions which get automatically or 
> temporarily "deactivated" or entries that represent contracts whose 
> lifetime should not be disclosed to most of the services etc. pp.

And what of the services that do need to match on the lifetime (other than
with respect to the current time) ? This gets back to where I started this
thread; schema mechanisms are not appropriate for enforcing access controls.
They are immutable and affect everyone the same. You don't have the
discretion to have some services permitted to match the lifetimes and some
prohibited. With your syntaxes the directory administrator decides up front
that either all services and users can match the lifetimes or none will
(ever!). That is too inflexible. What you should be doing is extending the
access control mechanisms in OpenLDAP so that it is possible to express
which identities are permitted to apply which matching rules to which
attribute types. That, combined with the new matching rules, would allow
you to do everything you want to do with the new syntaxes and more besides.
It would allow access controls to be tailored for the needs of each service
and could be applied to syntaxes other than timestamps. It would also allow
tighter controls to be placed on existing attributes of Generalized Time syntax.

> 
> 
>> Fair enough that users shouldn't be able to see the service details
>> of other users, and maybe there are times when users shouldn't be
>> able to see some of their own service details, but putting blinkers
>> on the service as well doesn't seem worth it. For one thing it means
>> that the service can't do things like warn users that their access
>> will be disabled in one hour, or even determine for itself which
>> users will soon become disabled so that certain administrative actions 
>> can be put in motion.
> 
> Thus our above provisioning scenario profits from automatic processing
> the draft currently does not require to manage these fields during all 
> day standard operation (e.g. administration/authorization).
> Of course using another (generalizedTime syntax) attribute (in 
> contrast/addition to our two extra ones) would more or less support the 
>  administration and authorization goals you've mentioned for example above.

That's what I don't like about the new syntaxes. Each new authorization
criterion needs a new syntax, so we get a proliferation of new syntaxes
just like old syntaxes, but with special rules. Put the rules in the
access control models where they belong.

> 
> 
>>> 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...
>>
>> I know of no standard specification that explicitly allows or 
>> prohibits the use of any particular matching rule in an extensible
>> match. Yours would be the first.
> 
> Disclaimer: it's not our intention and we don't want to introduce a 
> major change or any quirky exceptions in LDAP. We try to solve a problem 
> making use of the existing standards and when forced to we just aim to 
> extend this standard as marginal as possible. We found a solution which 
> works for us by just implementing two matching rules and two 
> generalizedTime-derived attribute value syntaxes (and the assertion 
> syntax we have called "NOW").
> 
> All we currently are looking for is to get reliable information how 
> ordering matching rules are/should be commonly supported in extensible 
> matching rules. Depending from the answer we perhaps need the extra 
> syntaxes (when supported) or we perhaps don't need the extra syntaxes 
> (when not supported).

The answer is not useful. You seem to be assuming that if an attribute
is defined without an ordering matching rule, then it is not possible to
do an ordering match on values of the attribute except via an extensible
match. However, all the typical naming attributes (commonName, givenName,
organizationName, and so on) are defined without ordering matching rules,
yet most (if not all) implementations will readily perform <= and >=
filter matching on values of the attributes and allow the values to be
sorted. You can't rely on the absence of an ordering matching rule in
an attribute definition to prevent ordering matching of the attribute's
values. You should be looking at using access control mechanisms to do
that.

[snip]

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

There's no "may" about it. We do, and we use the capability extensively,
and it's not going away.

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

I would rather do that in the access control mechanisms.

[snip]

>> Even if you lock down the timestamps there is still plenty of other, 
>> more useful information that someone with the service's credentials 
>> could access.
>> The new syntaxes would provide only a marginal benefit
> 
> Not in the scenario we are focusing on, even more in case a server 
> supports ordering matching rules in extensible match filters - like your 
> product for example does.

The new syntaxes are not relevant if an entry is hidden. Once an entry
becomes visible the new syntaxes are only protecting timestamps for
which there is no service or user that ever needs to match their values
to something other than the current time.

Regards,
Steven

[snip]