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

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

Hi Steven,

Steven Legg wrote:

Hi Daniel, Daniel Pluta wrote:

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)


I don't have problem with a server publishing its time zone, but the
IESG might take exception to standardizing a feature for which no
particular purpose has been identified.
Yes we currently share the same concerns but in our opinion it's at least worth a try. In case publishing the "time" via the Root-DSE would be generally acceptable, we would suggest and vote for also publishing the server's timezone to make the common information about the time more complete. 



Incidentally, I can imagine scenarios where an administrator would
set up a server to report and operate as though it is in a time zone
other than the one it is physically in. It's better and easier for
the server to nominate its timezone rather than have to work it out
from the server's location.


Yes that would be the most reliable way.



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).
Not so much an opposite approach as a solution to a different requirement. I just mentioned it to indicate that I have a use for 
publishing the server's current time, not just in the root, but in
every entry. I wasn't offering it as an alternative solution to your
specific requirements.



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


Because it was easier to code it that way. A consistent time would be
 better but requires more coding. If I were to standardize this
attribute, then I would specify it as having its value fixed for the
duration of an operation, and change the code accordingly.



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. 

The periods are defined by the directory administrators in the access
 controls, which are evaluated by the server using the server's
current time. The client's aren't defining anything.


Regardless from our concerns, your currentTimeOfDay syntax is very
interesting, to extend our matching rules to also match these kind
of values, too.


I don't see what that would achieve. The value of currentTimeOfDay is
 always "now" and your matching rules are testing if the value of a
timestamp is "now", so the result would always be true (assuming the
implementation determined "now" only once for the entire operation).
Sorry that's my fault: I've meant the assertion value's syntax. Which in our scenario probably could become useful as attribute value syntax.
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.

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.

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



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



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. 



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).
Our draft is based on the assumption that ordering matching rules are supported in extensible matching rules, as long as the matching rules are compatible to the attribute value syntax. That's also the reason for our interim confusion regarding a reliable demand for the extra syntaxes after we have seen that openldap seems currently not to support ordering matching rules in extensible match filters.
Regardless of the temporary confusion we've used the "natural" schema definition mechanism (especially using the relation between a syntax and its associated/compatible matching rules). We understand this association the way that only "assigned/compatible" matching rules are/should be applicable to attributes of a distinct syntax (please correct me if I'm wrong). 

As you've previously explained, ordering matching rules are (at least by
your product) supported in extensible match filters. Sadly we both
are not aware of a detailed specification regarding this specific question.
But for sure I'm with you: personally I do not understand why ordering matching rules in common shouldn't be supported in extensible match filters. I also don't know whether this kind of support/feature is left open to each vendor because the specification does not say something about it. Therefore I've posted a question on openldap-technical in the meantime and I'm currently hoping for an answer (regardless whether product specific or not) which hopefully at least slightly enlightens me.
Although, missing support for ordering matching rules in extensible match filters (which seems to be the current status of openldap) would solve our non-disclosure problem (without the need for additional syntaxes), I would prefer the general support of syntactically compatible ordering matching rules in extensible matching filters, because ordering matching rule support could offer extra functionality (e.g. in case two or more different ordering matching rules are available for one attribute syntax).
To further discuss whether the introduction of our two extra syntaxes possibly makes sense or not, all we need to know in the moment is a clear statement regarding the intended/specified support for ordering matching rules 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.
FYI, eB2Bcom's directory allows all of its 110+ supported matching rules to be used in an extensible match. In fact, an extensible match 
is the only way to invoke a significant number of them. I'm not
convinced that the new syntaxes are necessary or desirable.




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.


An ACL engine in a directory is not itself subject to access
controls.


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

Best regards,
Daniel



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