[Date Prev][Date Next] [Chronological] [Thread] [Top]

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:

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]
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext