Re: [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:
>>>> Hi Daniel, Daniel Pluta wrote:
>>>>> Hi Steven, Steven Legg wrote:
>>>>>> Daniel Pluta wrote:
>>>>>>> Steven Legg wrote:
>>>>>>>> Daniel Pluta wrote:
>>
>>> 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.
> 
> Ok, that's fine.
> 
> 
>>> 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.
> 
> As we've written (above and in our draft, sect. 7.3) we prefer and have
> always preferred the Root-DSE. Publishing an additional operational
> attribute carrying the current time of the server (an entry is delivered
> from) has been mentioned (sect. 7.4) but left open for discussion to
> determine whether such kind of information is useful for someone else.

I'm already doing it so it is obviously useful to someone else (for something
else).

> 
> 
>> 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.
> 
> Unlike your suggested approach using filter statements like for example
> (&(currTime>=9:00)(currTime<=12:00)) to enable client side filtering for

FYI, for my purposes the filtering is done by the access control decision
function in the server using what is inevitably that server's current time.
Client's don't do any filtering and don't see currentTimeOfDay because
they don't ask for it.

> an operational attribute called e.g. currTime that contains the server's
> time during delivery our concept does not and has never had a need for 
> such kind of attribute.
> 
> With your argument concerning the distributed DIT in mind this entry
> local attribute does not seem to make sense (even in regard to your
> scenario) so we tend to remove sect. 7.4 from the draft.

Let me try to make it clearer. Suppose that we have a DIT for
o=Acme Corporation with two subunits ou=Sales and ou=Finance. Further
suppose that there are two LDAP/X.500 servers. The first server holds the
o=Acme Corporation entry and the entire ou=Sales subtree. The second
server just holds the entire ou=Finance subtree. Consider an LDAP client
that connects to the first server and issues a search for (cn=Smith) with
the base object ou=Finance,o=Acme Corporation. The first server does not
hold any entries in this subtree so it chains the search request to the
second server. The second server performs the search and returns the
resulting entries to the first server which then forwards them to the
LDAP client. The entries in the result have all come from the second
server, though they were delivered to the client by the first server.
If access controls on the second server used the "now" ordering matching
rule, or if the filter instead included a filter item with the
"now" ordering rule, then the rule would have been evaluated with respect
to the current time on the second server. However, if the client read
the current server time from the root DSE (necessarily in a separate
operation), then it would get the current time on the first server,
which wasn't the time used to determine the results of the person search.
In this scenario the client derives no benefit from knowing the current
server time from the root DSE because it is irrelevant to the person
search result. A current time attribute appearing in each entry gives
the time of the server that actually evaluated that particular entry
(in this case, the second server).

> 
> 
>>> 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.
> 
> That's fine and it complies with what we've suggested in sect. 6.2.
> 
> 
>> 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.
> 
> You're completely right here. We've also thought about that previously
> but canceled it because in our opinion this won't be a general but only
> a product specific solution.

There isn't a common, standardized access control model for LDAP that
you can extend, but that doesn't mean you have to standardize a poor
approach instead. It would be reasonable to have a non-normative
(informative) section or annex (or a separate draft) that describes
how the new matching rules (the normative part) can be used to protect
the privacy of timestamp values when used in conjunction with an access
control model that supports the ability to express what matching rules
can be applied to what attribute types. You could use an extended
OpenLDAP access control model as a concrete example. Anyone wanting to
achieve the same thing on a different platform would need to extend
their native access controls in an equivalent way, but would have the
guidance from the draft and the example from OpenLDAP to go by.

> 
> [snip]
> 
>> 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.
> 
> Many thanks for this explanation. We have not thought about this, yet.
> It obviously does not scale.
> 
> 
>> I would rather do that in the access control mechanisms.
> 
> We too. ;-)
> 
> [snip]
> 
> 
> Last but not least, towards an 01-version please let me give a first
> short summary regarding the intermediate status of our ongoing
> discussion (please feel free to comment):
> 
> 
> General remarks:
> - LDAP Server Side Current Time Matching seems to be of interest
> - Steven, many thanks for the discussion and your valuable feedback!
> 
> Attribute Value Syntaxes to enforce/denie some kind of access:
> - Doesn't seem to make sense in general - better use ACLs.
> - No need for the many syntactically dedicated ext. matching rule
> 
> Matching Rules:
> - Instead of all the extensible matching rules only two:
>   - equality matching rule: "nowMatch"
>   - ordering matching rule: "nowOrderingMatch"
>   - both matching rules support now and timely offset matching
>   - both matching rules support extensible match filters
> 
> Assertion Syntaxes:
> - Two standalone assertion syntaxes preferred:
>   - simple "NOW"
>   - flexible X.680 (based on your already avail. implementation)
>   - both compatible with the above matching rules
> - Alternative:
>   Differentiation between "now" and "nowOffset" assertion syntax
>   not strictly needed: both can be integrated in one "Assertion
>   Syntax" that supports any offset (also "NOW" using some kind
>   of a zero offset?).

Whether that differentiation is needed depends on how one extends
the access control model. If there is only the offset assertion
syntax, then the extended access control model needs to be able to
express which identities can apply what matching rules *and*
*assertion* *values* to what attribute types. Note that you need
to be able to prevent the use of non-zero offsets to protect the
timestamps in the ways you want. If there is a nowMatch and a
separate nowOffsetMatch (likewise nowOrderingMatch and
nowOffsetOrderingMatch), then the extended access control model
only needs to be able to express which identities can apply what
matching rules to what attribute types. Only the nowMatch and
nowOrderingMatch rules would be allowed for a protected timestamp
attribute type. The nowOffsetMatch and nowOffsetOrderingMatch rules
would be prohibited, amongst other rules.

Of course, nowMatch is a special case of nowOffsetMatch and
nowOrderingMatch is a special case of nowOffsetOrderingMatch.

> - In my opinion: "NOW" would offer improved readability

Yes, except that there is an existing assertion syntax that you could
use. It is useful for interoperability with X.500 for each new LDAP
syntax to define its corresponding ASN.1 type. The assertion
syntax for the rules without offset carries no information, which would
naturally correspond to the ASN.1 NULL type. RFC 3687 defines
an LDAP syntax for the NULL type (1.2.36.79672281.1.5.1).

> 
> Operational Attribute for each Entry:
> - Distributed DIT could result in many different "NOW"s
>   - Currently there's no known use-case for something like this.

The use-case is the generalization for a distributed or virtualized DIT
of *your* use-case.

Regards,
Steven

>   - Remove from draft
> [- Nevertheless, keep it just for informational reasons]?!
> 
> Root-DSE:
> - "supportedFeature" seems to be ok
> - "serverTime" whether in UTC or <g-differential> format
>    - both seem to be reasonable
> 
> 
> Best regards,
> Daniel