Re: [ldapext] [Fwd: New Version Notification for draft-pluta-ldap-srv-side-current-time-match-00]
Steven Legg <steven.legg@eb2bcom.com> Fri, 16 April 2010 04:53 UTC
Return-Path: <steven.legg@eb2bcom.com>
X-Original-To: ldapext@core3.amsl.com
Delivered-To: ldapext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 697183A6403 for <ldapext@core3.amsl.com>; Thu, 15 Apr 2010 21:53:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.826
X-Spam-Level: **
X-Spam-Status: No, score=2.826 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_EQ_STATIC=1.172]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVIwldhqeLME for <ldapext@core3.amsl.com>; Thu, 15 Apr 2010 21:53:52 -0700 (PDT)
Received: from eb2bcom.com (165.203.232.72.static.reverse.ltdomains.com [72.232.203.165]) by core3.amsl.com (Postfix) with ESMTP id 1EF463A6B0E for <ldapext@ietf.org>; Thu, 15 Apr 2010 21:53:51 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=eb2bcom.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Source:X-Source-Args:X-Source-Dir; b=VU+kTEUU99YqfI8wOOuu+SG4ZsB/MJn6VSEqLRF73ixzLkJxKXcfLasNV8IHle7JqYZ4itqW393GH4VBdPLUPE2KSfJP1AbNp4oLu90tGStoqE7wGv+YMi95ew8bU40t;
Received: from eth3065.vic.adsl.internode.on.net ([150.101.156.248] helo=[192.168.1.161]) by host.eb2bcom.com with esmtpa (Exim 4.69) (envelope-from <steven.legg@eb2bcom.com>) id 1O2dYl-00018m-IU; Fri, 16 Apr 2010 14:53:44 +1000
Message-ID: <4BC7ED51.7030806@eb2bcom.com>
Date: Fri, 16 Apr 2010 14:53:37 +1000
From: Steven Legg <steven.legg@eb2bcom.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Daniel Pluta <pluta@tum.de>
References: <4BAFB1A7.30609@tum.de>
In-Reply-To: <4BAFB1A7.30609@tum.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.eb2bcom.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - eb2bcom.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: hommel@lrz.de, ldapext@ietf.org
Subject: Re: [ldapext] [Fwd: New Version Notification for draft-pluta-ldap-srv-side-current-time-match-00]
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldapext>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Apr 2010 04:53:53 -0000
Hi Daniel, 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] [Fwd: New Version Notification for draf… Daniel Pluta
- Re: [ldapext] [Fwd: New Version Notification for … Steven Legg
- Re: [ldapext] [Fwd: New Version Notification for … Daniel Pluta
- Re: [ldapext] [Fwd: New Version Notification for … Steven Legg
- Re: [ldapext] [Fwd: New Version Notification for … Daniel Pluta
- Re: [ldapext] [Fwd: New Version Notification for … Steven Legg
- Re: [ldapext] [Fwd: New Version Notification for … Daniel Pluta
- Re: [ldapext] [Fwd: New Version Notification for … Daniel Pluta
- Re: [ldapext] [Fwd: New Version Notification for … Steven Legg
- Re: [ldapext] [Fwd: New Version Notification for … Daniel Pluta
- Re: [ldapext] [Fwd: New Version Notification for … Steven Legg
- Re: [ldapext] [Fwd: New Version Notification for … Daniel Pluta
- Re: [ldapext] [Fwd: New Version Notification for … Steven Legg
- Re: [ldapext] [Fwd: New Version Notification for … Daniel Pluta
- Re: [ldapext] [Fwd: New Version Notification for … Steven Legg
- Re: [ldapext] [Fwd: New Version Notification for … Daniel Pluta
- Re: [ldapext] [Fwd: New Version Notification for … Steven Legg
- Re: [ldapext] [Fwd: New Version Notification for … Daniel Pluta
- Re: [ldapext] [Fwd: New Version Notification for … Steven Legg
- Re: [ldapext] [Fwd: New Version Notification for … Daniel Pluta
- Re: [ldapext] [Fwd: New Version Notification for … Steven Legg