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

[Steven Legg <steven.legg@eb2bcom.com>]

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:
> > > > > > Hi Daniel, Daniel Pluta wrote:
> > > > > > > Hi Steven, Steven Legg wrote:
> > > > > > > > Daniel Pluta wrote:
> > > > > > > > > Steven Legg wrote:
> > > > > > > > > > Daniel Pluta wrote:

[snip]

> > > > > 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.
>
> Just a short remark: Daylight saving time possibly reduces the grade of 
> usefulness of this information in general, nevertheless I think it 
> should be at least optional to be used instead of UTC time.

In eB2bcom's implementation the local time part always reflects the time
on local clocks for users in the same region as the server, but the
timezone part changes depending on daylight saving time (where I'm sitting
now, the timezone is either +10:00 or +11:00 depending on the time of year).
Thus UTC is always correct and local time is always appropriate.
It isn't possible to know whether a server is on daylight savings time
from the timestamp alone, but we've never had a need to know.

> > > > 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.
>
> I already had a look into OpenLDAP sources: It's quite not easy to 
> implement some kind of search-privilege limitation using for example a 
> matching rule white-/black-list attached to search privileges...
>
> I've already implemented a just-for-fun patch which successfully extends 
> the ACL-parsing to restrict search-privileges but applying the resulting 
> data structure during matching is currently nearly impossible without 
> major changes in OpenLDAP's current source.

Can't you examine the search filter before evaluating it to find the
disallowed combinations of attribute type and matching rule ? Any filter item
that is disallowed can be rewritten to be an undefined match, or the search
can be rejected, whichever makes sense. It ought to be possible to work out
which matching rules are going to be used on which attribute types without
actually waiting to see what happens. I'm assuming that permission to match
is determined only on the user identity (i.e., not dependent on the location
of the entry being accessed), which is still less restrictive than using
the new syntaxes.

> > > 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.
>
> Yes that would fulfill our original intentions in an ideal way - the 
> "only" difficulty regarding OpenLDAP's current source seems to be the 
> application of acl structures during matching.
>
> Another approach which currently also works for us:
> Using "filter=...." statements in current OpenLDAP ACLs fulfills our 
> requirements, too. Because this filtering takes place in the last step 
> (right before delivery).
>
> This acl-filter is not applied in the user-context thus the user does 
> not need access to the time-stamp attributes at all. Instead the server 
> processes this filter in its own context.
>
> Possible disadvantage: it could happen that an user's requested search 
> uses "(objectClass=*)" which results in a huge result set, which will be 
> reduced two 1 entry during the final filtering step in the server.
>
> A probably more efficient approach would be:
> Using the rewrite module to dynamically add limiting filter expressions 
> to incoming user requests:
>
> (ojbectClass=*) ==slapo-rwm==> (&(objectClass=*)(limit1)(limit2)).
>
> Such extended/limiting filters would lead to initially smaller result 
> sets in the first step. Additionall the final server-context-filtering 
> could be skipped completely. The only (big) problem as the filter is 
> rewritten in the user's context the user needs search permissions on the 
> attribute. Granting common search privileges do not fulfill our privacy 
> scenarios because inappropriate matching rules can be chosen using 
> extensible match filters. Thus the search-permission should be further 
> narrowed e.g. on attribute to matching rule association basis...
>
>
> > > - 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).
>
> Ohh yeah!  :-/
>
> Although I understand the idea behind this type and also your suggestion 
> I'm just not very happy with this syntax only because there is no ASN.1 
> definition for a an abstract type like "the current time" (additionally 
> to the ISO8601 specified common "point in time" for example). On the 
> other hand: the comparison takes place on server side so we do not (need 
> to) send any value to be compared which justifies to indicate this by 
> NULL, e.g. using "(timeAttr=)" as a filter.
>
> Nevertheless I'm not happy with this especially in regard to 
> usability/readability.
>
> Even more, Am I right that a valid filter expression would look like: 
> (timeAttr=NULL) in case the LDAP string representation is "NULL"? If yes 
> in my personal opinion I would prefer to use "NOW" instead of "NULL".

The filter would look like (timeAttr:nowMatch:=NULL). An equality
match filter item applies the equality matching rule of the attribute type
using an assertion value of the syntax of that matching rule. The nowMatch
rule is not, and cannot be, the equality matching rule of timeAttr, so
(timeAttr=NOW) is bogus.

> Focused on the LDAP string representation: sending "NULL" instead of 
> "NOW" seems to be not more than an ineffectual misuse to me. Even "" 
> (the empty string) would be preferable instead of "NULL" in my opinion.
>
> So, let me just try to justify the use of "NOW" instead of "NULL": the 
> latter needs 33% additional resources! ;-)

NULL is already a standard syntax, so adding another syntax with an underlying
ASN.1 type of NULL is 100% additional resources :-)

Regards,
Steven

> > > 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.
>
> As stated above this makes of course sense - NOW. ;-)
> Many thanks for the scenario!
>
>
> Best regards,
> Daniel
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext