From ldapext-bounces@ietf.org Thu Oct 21 08:27:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14913 for ; Thu, 21 Oct 2004 08:27:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKb3M-0005wT-CH; Thu, 21 Oct 2004 07:24:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKRQt-0007yR-5U for ldapext@megatron.ietf.org; Wed, 20 Oct 2004 21:07:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00775 for ; Wed, 20 Oct 2004 21:07:51 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKRdH-0007Dx-09 for ldapext@ietf.org; Wed, 20 Oct 2004 21:20:50 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9L17kZv005518 for ; Thu, 21 Oct 2004 01:07:46 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041020175617.033b0df8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 20 Oct 2004 18:08:25 -0700 To: ldapext@ietf.org From: "Kurt D. Zeilenga" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This I-D describes an extension we've found to be quite useful in provisioning applications, Modify-Increment. When combined with a read-entry control, one can increment value(s) of an attribute and read-back the values, in one atomic operation. Pretty simple. The catch is that it extends the Modify operation enumeration. I'm guessing servers which don't implement this extension would return protocolError. If there are servers which would have a more adverse reaction, I might raise the feature discover bar a bit to avoid such. Comments? Kurt >To: i-d-announce@ietf.org >From: Internet-Drafts@ietf.org >Date: Wed, 20 Oct 2004 10:36:31 -0400 >Subject: I-D ACTION:draft-zeilenga-ldap-incr-00.txt >Reply-To: internet-drafts@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : LDAP Modify-Increment Extension > Author(s) : K. Zeilenga > Filename : draft-zeilenga-ldap-incr-00.txt > Pages : 5 > Date : 2004-10-19 > >This document describes an extension to the Lightweight Directory > Access Protocol (LDAP) Modify operation to support an increment > capability. This extension is useful in provisioning applications, > especially when combined with the assertion control and/or the > pre-read or post-read control extension. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-incr-00.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-zeilenga-ldap-incr-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-zeilenga-ldap-incr-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-10-20105028.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-zeilenga-ldap-incr-00.txt > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Oct 21 09:34:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28171 for ; Thu, 21 Oct 2004 09:34:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKcos-00009l-AE; Thu, 21 Oct 2004 09:17:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKcDd-0007AO-NJ for ldapext@megatron.ietf.org; Thu, 21 Oct 2004 08:39:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17898 for ; Thu, 21 Oct 2004 08:38:59 -0400 (EDT) Received: from gort.hpl.hp.com ([192.6.10.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcQF-0000B5-EN for ldapext@ietf.org; Thu, 21 Oct 2004 08:52:04 -0400 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by gort.hpl.hp.com (8.12.10/8.12.10) with ESMTP id i9LCccj3025322 for ; Thu, 21 Oct 2004 13:38:38 +0100 (BST) Received: from dunbar-n-1.hpl.hp.com (dunbar-n-1.hpl.hp.com [15.144.26.129]) by otter.hpl.hp.com (8.9.3 (PHNE_25183+JAGae58098)/HP-Labs Bristol Internal Mail Hub) with ESMTP id NAA06849 for ; Thu, 21 Oct 2004 13:38:37 +0100 (BST) Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt From: Neil Dunbar To: ldapext@ietf.org In-Reply-To: <6.1.2.0.0.20041020175617.033b0df8@127.0.0.1> References: <6.1.2.0.0.20041020175617.033b0df8@127.0.0.1> Content-Type: text/plain Organization: Managed Directories, MSGD, HP Services Date: Thu, 21 Oct 2004 13:38:24 +0100 Message-Id: <1098362304.29264.4.camel@dunbar-n-1.hpl.hp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit X-HPL-MailScanner-Information: Please contact the Helpdesk for more information X-HPL-MailScanner: Found to be clean X-HPL-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-2.686, required 5, autolearn=not spam, ALL_TRUSTED -0.84, AWL 0.76, BAYES_00 -2.60) X-MailScanner-From: neil.dunbar@hp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit On Wed, 2004-10-20 at 18:08 -0700, Kurt D. Zeilenga wrote: > This I-D describes an extension we've found to be quite > useful in provisioning applications, Modify-Increment. > When combined with a read-entry control, one can increment > value(s) of an attribute and read-back the values, in one > atomic operation. Pretty simple. What should a server return if an increment is requested on an attribute with a non-discrete domain of values? (eg, increment on a string value). I suppose Unwilling To Perform would be OK; Constraint Violation perhaps. Undefined Type doesn't seem right. Cheers, Neil _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Oct 21 11:09:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11204 for ; Thu, 21 Oct 2004 11:09:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKeQo-0003rJ-CO; Thu, 21 Oct 2004 11:00:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKeBT-0003vX-Vg for ldapext@megatron.ietf.org; Thu, 21 Oct 2004 10:44:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08337 for ; Thu, 21 Oct 2004 10:44:53 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeO7-0004t1-5n for ldapext@ietf.org; Thu, 21 Oct 2004 10:57:59 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9LEidZv009873; Thu, 21 Oct 2004 14:44:39 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041021074335.02e56a68@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 21 Oct 2004 07:45:17 -0700 To: Neil Dunbar From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt In-Reply-To: <1098362304.29264.4.camel@dunbar-n-1.hpl.hp.com> References: <6.1.2.0.0.20041020175617.033b0df8@127.0.0.1> <1098362304.29264.4.camel@dunbar-n-1.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 05:38 AM 10/21/2004, Neil Dunbar wrote: >On Wed, 2004-10-20 at 18:08 -0700, Kurt D. Zeilenga wrote: >> This I-D describes an extension we've found to be quite >> useful in provisioning applications, Modify-Increment. >> When combined with a read-entry control, one can increment >> value(s) of an attribute and read-back the values, in one >> atomic operation. Pretty simple. > >What should a server return if an increment is requested on an attribute >with a non-discrete domain of values? (eg, increment on a string value). > >I suppose Unwilling To Perform would be OK; Constraint Violation >perhaps. Undefined Type doesn't seem right. Our implementation returns constraintViolation, which I feel is the more appropriate result code than unwillingToPerform. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Oct 21 11:31:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13501 for ; Thu, 21 Oct 2004 11:31:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKekg-00041Q-L5; Thu, 21 Oct 2004 11:21:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKebF-0008VU-53 for ldapext@megatron.ietf.org; Thu, 21 Oct 2004 11:11:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11497 for ; Thu, 21 Oct 2004 11:11:30 -0400 (EDT) Received: from [69.145.82.195] (helo=mail.montana.boreham.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKens-0005Zz-Cv for ldapext@ietf.org; Thu, 21 Oct 2004 11:24:37 -0400 Received: from squirrel (unknown [69.145.82.218]) by mail.montana.boreham.org (Postfix) with SMTP id 6646111037C for ; Thu, 21 Oct 2004 08:10:58 -0700 (PDT) Message-ID: <043201c4b780$7695c440$da529145@mtbrook.bozemanpass.com> From: "David Boreham" To: References: <6.1.2.0.0.20041020175617.033b0df8@127.0.0.1> Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt Date: Thu, 21 Oct 2004 08:13:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Is it intended that this feature work with replication ? _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Oct 21 12:45:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21653 for ; Thu, 21 Oct 2004 12:45:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKfnB-0001Lr-75; Thu, 21 Oct 2004 12:27:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKfiY-0007Qf-Dz for ldapext@megatron.ietf.org; Thu, 21 Oct 2004 12:23:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19346 for ; Thu, 21 Oct 2004 12:23:07 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKfvC-0007KD-Gq for ldapext@ietf.org; Thu, 21 Oct 2004 12:36:15 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9LGN5Zv010522; Thu, 21 Oct 2004 16:23:05 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041021090823.02d578b0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 21 Oct 2004 09:23:43 -0700 To: "David Boreham" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt In-Reply-To: <043201c4b780$7695c440$da529145@mtbrook.bozemanpass.com> References: <6.1.2.0.0.20041020175617.033b0df8@127.0.0.1> <043201c4b780$7695c440$da529145@mtbrook.bozemanpass.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 08:13 AM 10/21/2004, David Boreham wrote: >Is it intended that this feature work with replication ? Yes. The client can update the master using Modify-Increment. The master can then replicate the DIT change to shadows (and these to other shadows). If the replication protocol supports expression of an Modify-Increment change, that can be used directly. Otherwise, the change can be expressed as one would a Modify-Replace. We support two replication protocols in OpenLDAP. In one (a log-based push protocol), the Modify-Increment capability of that protocol is used. In the other (a state-based pull protocol), the resulting DIT values are transferred. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Oct 21 12:59:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23167 for ; Thu, 21 Oct 2004 12:59:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKg5T-0001Y8-HC; Thu, 21 Oct 2004 12:46:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKg1T-0006FY-Dt for ldapext@megatron.ietf.org; Thu, 21 Oct 2004 12:42:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21401 for ; Thu, 21 Oct 2004 12:42:40 -0400 (EDT) Received: from [69.145.82.195] (helo=mail.montana.boreham.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgE7-0007nn-Cs for ldapext@ietf.org; Thu, 21 Oct 2004 12:55:48 -0400 Received: from squirrel (unknown [69.145.82.218]) by mail.montana.boreham.org (Postfix) with SMTP id 1008D11037C for ; Thu, 21 Oct 2004 09:42:06 -0700 (PDT) Message-ID: <04e301c4b78d$317ffe40$da529145@mtbrook.bozemanpass.com> From: "David Boreham" To: References: <6.1.2.0.0.20041020175617.033b0df8@127.0.0.1> <043201c4b780$7695c440$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021090823.02d578b0@127.0.0.1> Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt Date: Thu, 21 Oct 2004 09:44:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit > At 08:13 AM 10/21/2004, David Boreham wrote: >>Is it intended that this feature work with replication ? > > Yes. The client can update the master using Modify-Increment. > The master can then replicate the DIT change to shadows > (and these to other shadows). If the replication protocol > supports expression of an Modify-Increment change, that can > be used directly. Otherwise, the change can be expressed > as one would a Modify-Replace. > > We support two replication protocols in OpenLDAP. In > one (a log-based push protocol), the Modify-Increment > capability of that protocol is used. In the other (a > state-based pull protocol), the resulting DIT values > are transferred. I see. So in some cases this feature wouldn't work (in that it would no longer guarantee atomicity) ? In the case that you do use an atomic replication propagation operation, what happens when two clients have independently successfully completed a supposedly atomic increment operation upon two different servers ? Is it sufficient that one client receives the wrong result (at least wrong in that another client could receive exactly the same value, talking to another server) ? Should there be a way for clients to discover if the feature will work or not ? (or perhaps it shouldn't be enabled on servers that are participating in replication mechanisms that renders its effects non-atomic?). _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Oct 21 14:00:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29572 for ; Thu, 21 Oct 2004 14:00:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgzt-0005sI-1k; Thu, 21 Oct 2004 13:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgm5-0005kh-AB for ldapext@megatron.ietf.org; Thu, 21 Oct 2004 13:30:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26095 for ; Thu, 21 Oct 2004 13:30:49 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgyj-0000bg-SU for ldapext@ietf.org; Thu, 21 Oct 2004 13:43:58 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9LHUZZv010989; Thu, 21 Oct 2004 17:30:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041021101612.02d7f2d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 21 Oct 2004 10:31:13 -0700 To: "David Boreham" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt In-Reply-To: <04e301c4b78d$317ffe40$da529145@mtbrook.bozemanpass.com> References: <6.1.2.0.0.20041020175617.033b0df8@127.0.0.1> <043201c4b780$7695c440$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021090823.02d578b0@127.0.0.1> <04e301c4b78d$317ffe40$da529145@mtbrook.bozemanpass.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Like LDAP, this extension to LDAP is designed to be used in directory systems which act in accordance with X.500. If one is using this extension in a system which doesn't adhere single-master aspects of the X.500 data model, lots of more than this operation will lead to application problems. I discuss these problems in draft-zeilenga-ldup-harmful (currently expired, I will refresh shortly). For instance, applications which incrementing values using Modify-Delete+Add would suffer from the lack of ACID properties in the multi-master system. Likewise, applications which used Modify-Increment would suffer from the lack of ACID properties in the multi-master systems. In LDAP, clients may presume server is acting in accordance with the X.500 data model. If the server is unable or unwilling to do that, then it should not provide service. Clients which do desire an alternative service model should explicit request that model (through a request control or other mechanism). And, as far as how to perform this operation (or any other operation) within an alternative service model, I will leave that those who desire to specify alternative service models. Kurt At 09:44 AM 10/21/2004, David Boreham wrote: >>At 08:13 AM 10/21/2004, David Boreham wrote: >>>Is it intended that this feature work with replication ? >>Yes. The client can update the master using Modify-Increment. >>The master can then replicate the DIT change to shadows >>(and these to other shadows). If the replication protocol >>supports expression of an Modify-Increment change, that can >>be used directly. Otherwise, the change can be expressed >>as one would a Modify-Replace. >>We support two replication protocols in OpenLDAP. In >>one (a log-based push protocol), the Modify-Increment >>capability of that protocol is used. In the other (a >>state-based pull protocol), the resulting DIT values >>are transferred. > >I see. So in some cases this feature wouldn't work (in that it would no longer guarantee atomicity) ? >In the case that you do use an atomic replication propagation >operation, what happens when two clients have independently successfully completed >a supposedly atomic increment operation upon two different servers ? Is it sufficient that one client >receives the wrong result (at least wrong in that >another client could receive exactly the same value, >talking to another server) ? > >Should there be a way for clients to discover if the >feature will work or not ? (or perhaps it shouldn't be >enabled on servers that are participating in replication >mechanisms that renders its effects non-atomic?). > > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Oct 21 14:17:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01633 for ; Thu, 21 Oct 2004 14:17:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhKc-0000XV-6a; Thu, 21 Oct 2004 14:06:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKh0Z-0006aY-8m for ldapext@megatron.ietf.org; Thu, 21 Oct 2004 13:45:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28375 for ; Thu, 21 Oct 2004 13:45:49 -0400 (EDT) Received: from [69.145.82.195] (helo=mail.montana.boreham.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhDC-0001EY-F3 for ldapext@ietf.org; Thu, 21 Oct 2004 13:58:56 -0400 Received: from squirrel (unknown [69.145.82.218]) by mail.montana.boreham.org (Postfix) with SMTP id 0961A11037E for ; Thu, 21 Oct 2004 10:45:15 -0700 (PDT) Message-ID: <053601c4b795$b8b9f020$da529145@mtbrook.bozemanpass.com> From: "David Boreham" To: References: <6.1.2.0.0.20041020175617.033b0df8@127.0.0.1> <043201c4b780$7695c440$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021090823.02d578b0@127.0.0.1> <04e301c4b78d$317ffe40$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021101612.02d7f2d0@127.0.0.1> Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt Date: Thu, 21 Oct 2004 10:45:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit > In LDAP, clients may presume server is acting in accordance > with the X.500 data model. If the server is unable or > unwilling to do that, then it should not provide service. I see, I think you've answered my question: this feaure should not be implemented by servers that are participating in a multimaster replication mechanism with respect to the entry being modified (unless the server does something unusual to deliver the required consistency guarantees such as using 2-phase commit). It might be worth noting this in the draft, for those who might ask this question in the future. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Oct 21 18:34:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16695 for ; Thu, 21 Oct 2004 18:34:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKkar-0004SN-1m; Thu, 21 Oct 2004 17:35:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKivs-0003ng-9I for ldapext@megatron.ietf.org; Thu, 21 Oct 2004 15:49:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12889 for ; Thu, 21 Oct 2004 15:49:06 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKj8Y-0004q8-8x for ldapext@ietf.org; Thu, 21 Oct 2004 16:02:14 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9LJmXZv011873; Thu, 21 Oct 2004 19:48:33 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041021120228.03062090@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 21 Oct 2004 12:49:11 -0700 To: "David Boreham" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt In-Reply-To: <053601c4b795$b8b9f020$da529145@mtbrook.bozemanpass.com> References: <6.1.2.0.0.20041020175617.033b0df8@127.0.0.1> <043201c4b780$7695c440$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021090823.02d578b0@127.0.0.1> <04e301c4b78d$317ffe40$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021101612.02d7f2d0@127.0.0.1> <053601c4b795$b8b9f020$da529145@mtbrook.bozemanpass.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 10:45 AM 10/21/2004, David Boreham wrote: >>In LDAP, clients may presume server is acting in accordance >>with the X.500 data model. If the server is unable or >>unwilling to do that, then it should not provide service. > >I see, I think you've answered my question: this >feaure should not be implemented by servers that >are participating in a multimaster replication mechanism >with respect to the entry being modified (unless the >server does something unusual to deliver the >required consistency guarantees such as using 2-phase >commit). It's my view that servers which are 'participating in a multimaster replication mechanism' are not LDAP servers. LDAP servers, aside from communicating using LDAP PDUs, act in accordance with X.500. While the servers you refer might communicate using LDAP PDUs, they are not acting in accordance with X.500 and hence, in my view, are not LDAP servers. >It might be worth noting this in the draft, for those >who might ask this question in the future. I think its sufficient to specify that LDAP servers are to act in accordance with X.500. This I-D does so by incorporating [Roadmap]. That said, I think it would be good to note to the community the harm that truly non-optional introduction of MMR might have on existing directory applications, to reiterate to implementors that LDAP servers are to act in accordance with X.500, and encourage those who desire a different service model to design and specify a system that offers it. That system could be based on LDAP, but if so, it should engineered as a truly optional extension to LDAP. (For those who don't grok the terms "truly optional" or "truly non-optional", I refer you to discussion of the "MAY" keyword in RFC 2119). Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Oct 21 21:24:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22782 for ; Thu, 21 Oct 2004 21:24:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlYK-0004G3-Sb; Thu, 21 Oct 2004 18:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKl0E-0000Dt-G9 for ldapext@megatron.ietf.org; Thu, 21 Oct 2004 18:01:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09516 for ; Thu, 21 Oct 2004 18:01:43 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKlCv-0004JM-5a for ldapext@ietf.org; Thu, 21 Oct 2004 18:14:53 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9LM1hZv012531; Thu, 21 Oct 2004 22:01:43 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041021142725.02f75108@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 21 Oct 2004 15:02:21 -0700 To: ietf-pkix@imc.org From: "Kurt D. Zeilenga" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: ldapext@ietf.org Subject: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-x509-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At IETF#60, I stated that I would submit an I-D providing LDAP schema descriptions for the certificate related elements covered in RFC 2252/2256 but not covered in LDAPBIS syntax/schema I-Ds, with matching rule corrections. Though a submitted later than I had hoped, this is that I-D. This I-D assumes familiarity with X.509 and other normative references. In addition, to the these elements, this document provides LDAP schema descriptions for the elements discussed in RFC 2587, namely the X.509 pkiUser and pkiCA classes. Additionally, a few additional X.509 certificate related matching rules were included for completeness. The introduction of these rules requires introduction of new LDAP syntaxes for the assertion values. With the exception of one syntax, these LDAP syntaxes are GSER-based. The exception, certificateExactAssertion, utilizes the syntax suggested by RFC 3876. In a sequence revision of the I-D, ABNF grammars for each of the GSER-based formats will be provided for informational purposes. As noted at IETF#60, the intent of this I-D is to provide an RFC 2252/RFC2256 compatible specification for these X.500 schema elements. Hence, unlike the latest revisions of draft-ietf-pkix-ldap-pki, this I-D mandates the use of the ;binary transfer option to request and transfer certificate (and related) attribute values. There are a few other differences between this I-D and draft-ietf-pkix-ldap-pki. For instance, this I-D doesn't offer LDAP schema descriptions for 'cpCPS' and 'pkiCertPath' object classes and related attribute types, matching rules, and syntaxes. Lastly, I did not attempt to state an applicability statement for use of LDAP in Public Key Infrastructures. This, I believe, is better left to separate I-D, possibly titled "Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv3". I intend to leave that to others authors. Comments welcomed. Also, if there is available PKIX session time at IETF#61, I would be happy to present proposal(s) to reconcile any issues with this I-D. Enjoy! Kurt >To: i-d-announce@ietf.org >From: Internet-Drafts@ietf.org >Date: Wed, 20 Oct 2004 10:36:40 -0400 >Subject: I-D ACTION:draft-zeilenga-ldap-x509-00.txt >Reply-To: internet-drafts@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : LDAP X.509 Certificate Schema > Author(s) : K. Zeilenga > Filename : draft-zeilenga-ldap-x509-00.txt > Pages : 16 > Date : 2004-10-19 > >This document describes schema for representing X.509 certificates, > X.521 security information, and related elements in directories > accessible using the Lightweight Directory Access Protocol (LDAP). > The LDAP definitions for these X.509 and X.521 schema elements > replaces those provided in RFC 2252 and RFC 2256. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-x509-00.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-zeilenga-ldap-x509-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-zeilenga-ldap-x509-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-10-20105033.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-zeilenga-ldap-x509-00.txt > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Oct 21 21:48:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27269 for ; Thu, 21 Oct 2004 21:48:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoD1-0008Tj-Ml; Thu, 21 Oct 2004 21:27:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKmA0-00058r-Gk for ldapext@megatron.ietf.org; Thu, 21 Oct 2004 19:15:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25799 for ; Thu, 21 Oct 2004 19:15:47 -0400 (EDT) Received: from [69.145.82.195] (helo=mail.montana.boreham.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKmMc-0000df-FO for ldapext@ietf.org; Thu, 21 Oct 2004 19:28:59 -0400 Received: from squirrel (unknown [69.145.82.218]) by mail.montana.boreham.org (Postfix) with SMTP id 5BC7F11037C for ; Thu, 21 Oct 2004 16:15:13 -0700 (PDT) Message-ID: <077c01c4b7c3$d140b100$da529145@mtbrook.bozemanpass.com> From: "David Boreham" To: References: <6.1.2.0.0.20041020175617.033b0df8@127.0.0.1><043201c4b780$7695c440$da529145@mtbrook.bozemanpass.com><6.1.2.0.0.20041021090823.02d578b0@127.0.0.1><04e301c4b78d$317ffe40$da529145@mtbrook.bozemanpass.com><6.1.2.0.0.20041021101612.02d7f2d0@127.0.0.1><053601c4b795$b8b9f020$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021120228.03062090@127.0.0.1> Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt Date: Thu, 21 Oct 2004 16:15:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit > It's my view that servers which are 'participating in > a multimaster replication mechanism' are not LDAP servers. > LDAP servers, aside from communicating using LDAP PDUs, > act in accordance with X.500. While the servers you > refer might communicate using LDAP PDUs, they are not > acting in accordance with X.500 and hence, in my view, > are not LDAP servers. Can you cite (or quote) a section from X.500 that backs up this assertion ? _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Oct 21 21:52:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27810 for ; Thu, 21 Oct 2004 21:52:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoFz-00077D-OF; Thu, 21 Oct 2004 21:30:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKmkp-0003nx-Mw for ldapext@megatron.ietf.org; Thu, 21 Oct 2004 19:53:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04680 for ; Thu, 21 Oct 2004 19:53:55 -0400 (EDT) Received: from amos.eb2b.com.au ([210.8.191.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKmxW-0003WX-6J for ldapext@ietf.org; Thu, 21 Oct 2004 20:07:07 -0400 Received: from [192.168.1.155] (210.8.191.250) by amos.eb2b.com.au (7.1.016.1) (authenticated as andrew.sciberras) id 416CAD3800000EB0; Fri, 22 Oct 2004 10:02:22 +1000 Message-ID: <41784B9E.8080908@eB2Bcom.com> Date: Fri, 22 Oct 2004 09:51:58 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-au, en-gb, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" , Ldapext Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Subject: [ldapext] [Fwd: I-D ACTION:draft-sciberras-xed-eldif-03.txt] X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew.sciberras@eB2Bcom.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit FYI, I have created a new version of the ELDIF draft. Kurt your earlier comments on this draft have been taken into account and can be seen in this latest version. Regards, Andrew Sciberras eB2B.com Pty Ltd ---------- Forwarded message ---------- From: internet-drafts@ietf.org Date: Thu, 21 Oct 2004 15:49:40 -0400 Subject: I-D ACTION:draft-sciberras-xed-eldif-03.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Extended LDAP Data Interchange Format (ELDIF) Author(s) : A. Sciberras, S. Legg Filename : draft-sciberras-xed-eldif-03.txt Pages : 9 Date : 2004-10-21 This document extends the Lightweight Directory Access Protocol (LDAP) Data Interchange Format (LDIF) to permit Extensible Markup Language (XML) encoded directory attribute values to be represented in a human readable format, instead of Base64. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sciberras-xed-eldif-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-sciberras-xed-eldif-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-sciberras-xed-eldif-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ENCODING mime FILE /internet-drafts/draft-sciberras-xed-eldif-03.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Oct 21 21:54:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28285 for ; Thu, 21 Oct 2004 21:54:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoGw-0001G3-4R; Thu, 21 Oct 2004 21:31:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKmxu-0000kd-Bn for ldapext@megatron.ietf.org; Thu, 21 Oct 2004 20:07:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07540 for ; Thu, 21 Oct 2004 20:07:27 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKnAb-0004Xw-3E for ldapext@ietf.org; Thu, 21 Oct 2004 20:20:37 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9M07OZv013400; Fri, 22 Oct 2004 00:07:24 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041021165327.030cb3c0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 21 Oct 2004 17:08:02 -0700 To: andrew.sciberras@eb2bcom.com, steven.legg@eb2bcom.com From: "Kurt D. Zeilenga" In-Reply-To: <200410211949.PAA12956@ietf.org> References: <200410211949.PAA12956@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: ldapext@ietf.org Subject: [ldapext] Re: I-D ACTION:draft-sciberras-xed-eldif-03.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org I really hate the empty line caused by the trailing EOL of the XML value. I think this will lead to confusion. I suggest replacing xml-value-spec with: xml-value-spec = ">:" FILL SEP RANGLE XML-STRING RANGLE SEP ; See section 3.4 for details to avoid this problem. For the example, that would produce postalAddress;transfer-rxer>: > > > 250 Bay Street > Brighton Victoria 3186 > Australia > > sn: Sciberras And for a like XML value which didn't have a trailing EOL character, postalAddress;transfer-rxer>: > > > 250 Bay Street > Brighton Victoria 3186 > Australia >> sn: Sciberras While this is also a bit of an oddity, I think it occur less often and not result in as many problems as empty line would. At 12:49 PM 10/21/2004, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : The Extended LDAP Data Interchange Format (ELDIF) > Author(s) : A. Sciberras, S. Legg > Filename : draft-sciberras-xed-eldif-03.txt > Pages : 9 > Date : 2004-10-21 > >This document extends the Lightweight Directory Access Protocol >(LDAP) Data Interchange Format (LDIF) to permit Extensible Markup >Language (XML) encoded directory attribute values to be represented >in a human readable format, instead of Base64. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-sciberras-xed-eldif-03.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-sciberras-xed-eldif-03.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-sciberras-xed-eldif-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-10-21154444.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-sciberras-xed-eldif-03.txt > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Oct 21 22:26:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02405 for ; Thu, 21 Oct 2004 22:26:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoyO-0006I5-Gl; Thu, 21 Oct 2004 22:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoiQ-0002U8-Bp for ldapext@megatron.ietf.org; Thu, 21 Oct 2004 21:59:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29122 for ; Thu, 21 Oct 2004 21:59:35 -0400 (EDT) Received: from amos.eb2b.com.au ([210.8.191.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKov7-0002Fa-Gq for ldapext@ietf.org; Thu, 21 Oct 2004 22:12:47 -0400 Received: from [192.168.1.155] (210.8.191.250) by amos.eb2b.com.au (7.1.016.1) (authenticated as andrew.sciberras) id 416CAD3800000F15; Fri, 22 Oct 2004 12:07:49 +1000 Message-ID: <41786906.1010807@eB2Bcom.com> Date: Fri, 22 Oct 2004 11:57:26 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-au, en-gb, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" , Ldapext , Steven Legg Subject: Re: [ldapext] Re: I-D ACTION:draft-sciberras-xed-eldif-03.txt References: <200410211949.PAA12956@ietf.org> <6.1.2.0.0.20041021165327.030cb3c0@127.0.0.1> In-Reply-To: <6.1.2.0.0.20041021165327.030cb3c0@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew.sciberras@eB2Bcom.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Hmm.... the problem actually lies in my example. Following the text within section 3.4, even if the last character of the XML data is a line separator then a RANGLE character should follow it. Using your examples, without changing my ABNF for xml-value-spec, the output should actually look like this: postalAddress;transfer-rxer>: > > > 250 Bay Street > Brighton Victoria 3186 > Australia > > sn: Sciberras postalAddress;transfer-rxer>: > > > 250 Bay Street > Brighton Victoria 3186 > Australia > sn: Sciberras I will make changes to the draft to correct this mistake and provide some addition clarification as to when RANGLE characters are inserted into the XML Value. Thanks for the comments, _________________________________________ Andrew Sciberras eB2Bcom - Software Engineer Kurt D. Zeilenga wrote: > I really hate the empty line caused by the trailing EOL > of the XML value. I think this will lead to confusion. > I suggest replacing xml-value-spec with: > > xml-value-spec = ">:" FILL SEP > RANGLE XML-STRING RANGLE SEP > ; See section 3.4 for details > > to avoid this problem. For the example, that would produce > > postalAddress;transfer-rxer>: > > > > > > 250 Bay Street > > Brighton Victoria 3186 > > Australia > > > > > sn: Sciberras > > And for a like XML value which didn't have a trailing EOL character, > > postalAddress;transfer-rxer>: > > > > > > 250 Bay Street > > Brighton Victoria 3186 > > Australia > >> > sn: Sciberras > > While this is also a bit of an oddity, I think it occur less > often and not result in as many problems as empty line would. > > At 12:49 PM 10/21/2004, Internet-Drafts@ietf.org wrote: > >>A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : The Extended LDAP Data Interchange Format (ELDIF) >> Author(s) : A. Sciberras, S. Legg >> Filename : draft-sciberras-xed-eldif-03.txt >> Pages : 9 >> Date : 2004-10-21 >> >>This document extends the Lightweight Directory Access Protocol >>(LDAP) Data Interchange Format (LDIF) to permit Extensible Markup >>Language (XML) encoded directory attribute values to be represented >>in a human readable format, instead of Base64. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-sciberras-xed-eldif-03.txt >> >>To remove yourself from the I-D Announcement list, send a message to >>i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>to change your subscription settings. >> >> >>Internet-Drafts are also available by anonymous FTP. Login with the username >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-sciberras-xed-eldif-03.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-sciberras-xed-eldif-03.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >>Content-Type: text/plain >>Content-ID: <2004-10-21154444.I-D@ietf.org> >> >>ENCODING mime >>FILE /internet-drafts/draft-sciberras-xed-eldif-03.txt >> >> >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Oct 21 23:57:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09152 for ; Thu, 21 Oct 2004 23:57:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKqSm-00077Q-6O; Thu, 21 Oct 2004 23:51:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKqJK-00011M-GK for ldapext@megatron.ietf.org; Thu, 21 Oct 2004 23:41:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08096 for ; Thu, 21 Oct 2004 23:41:46 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKqW3-0004K0-Cp for ldapext@ietf.org; Thu, 21 Oct 2004 23:54:59 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9M3fXZv014952; Fri, 22 Oct 2004 03:41:33 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041021192544.02d7f560@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 21 Oct 2004 20:42:11 -0700 To: "David Boreham" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt In-Reply-To: <077c01c4b7c3$d140b100$da529145@mtbrook.bozemanpass.com> References: <6.1.2.0.0.20041020175617.033b0df8@127.0.0.1> <043201c4b780$7695c440$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021090823.02d578b0@127.0.0.1> <04e301c4b78d$317ffe40$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021101612.02d7f2d0@127.0.0.1> <053601c4b795$b8b9f020$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021120228.03062090@127.0.0.1> <077c01c4b7c3$d140b100$da529145@mtbrook.bozemanpass.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 04:15 PM 10/21/2004, David Boreham wrote: >>It's my view that servers which are 'participating in >>a multimaster replication mechanism' are not LDAP servers. >>LDAP servers, aside from communicating using LDAP PDUs, >>act in accordance with X.500. While the servers you >>refer might communicate using LDAP PDUs, they are not >>acting in accordance with X.500 and hence, in my view, >>are not LDAP servers. > >Can you cite (or quote) a section from X.500 that backs up this assertion ? Though not definitive, you might also consider David Chadwick's "Understand X.500" . It gives some rationale as to why the ITU selected the (single) master copy scheme was for the Directory. If you want something definitive, I suggest you read X.525 and sections of X.501 describing the DSA Model. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Oct 22 13:42:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23704 for ; Fri, 22 Oct 2004 13:42:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3Lg-0008Gv-HT; Fri, 22 Oct 2004 13:37:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3GG-0007Nu-DX for ldapext@megatron.ietf.org; Fri, 22 Oct 2004 13:31:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23110 for ; Fri, 22 Oct 2004 13:31:27 -0400 (EDT) Received: from [69.145.82.195] (helo=mail.montana.boreham.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3T4-0002nH-Ha for ldapext@ietf.org; Fri, 22 Oct 2004 13:44:47 -0400 Received: from racoon (unknown [69.145.82.253]) by mail.montana.boreham.org (Postfix) with ESMTP id 318781102E5 for ; Fri, 22 Oct 2004 10:30:53 -0700 (PDT) Message-ID: <041c01c4b85c$deb1c1f0$fd529145@mtbrook.bozemanpass.com> From: "David Boreham" To: References: <6.1.2.0.0.20041020175617.033b0df8@127.0.0.1><043201c4b780$7695c440$da529145@mtbrook.bozemanpass.com><6.1.2.0.0.20041021090823.02d578b0@127.0.0.1><04e301c4b78d$317ffe40$da529145@mtbrook.bozemanpass.com><6.1.2.0.0.20041021101612.02d7f2d0@127.0.0.1><053601c4b795$b8b9f020$da529145@mtbrook.bozemanpass.com><6.1.2.0.0.20041021120228.03062090@127.0.0.1><077c01c4b7c3$d140b100$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021192544.02d7f560@127.0.0.1> Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt Date: Fri, 22 Oct 2004 10:30:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit >>Can you cite (or quote) a section from X.500 that backs up this assertion >>? > > Though not definitive, you might also consider David > Chadwick's "Understand X.500" > . > It gives some rationale as to why the ITU selected the > (single) master copy scheme was for the Directory. If > you want something definitive, I suggest you read X.525 and > sections of X.501 describing the DSA Model. Thanks. I wasn't really looking for tutorial advice, more a specific reference (like section so and so, subsection whatever, where it says the following : ...). Surely you must be able to come up with a hard reference to back up your assertion that multi master replication is fundamentally incompatible with X.500 and hence LDAP ? _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Oct 22 15:34:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02846 for ; Fri, 22 Oct 2004 15:34:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL59t-0002Is-2X; Fri, 22 Oct 2004 15:33:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL50i-0002J2-Jh for ldapext@megatron.ietf.org; Fri, 22 Oct 2004 15:23:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02052 for ; Fri, 22 Oct 2004 15:23:32 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL5DX-0004nB-Ok for ldapext@ietf.org; Fri, 22 Oct 2004 15:36:52 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9MJNHZv019323; Fri, 22 Oct 2004 19:23:18 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041022104451.03046470@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 22 Oct 2004 12:21:35 -0700 To: "David Boreham" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt In-Reply-To: <041c01c4b85c$deb1c1f0$fd529145@mtbrook.bozemanpass.com> References: <6.1.2.0.0.20041020175617.033b0df8@127.0.0.1> <043201c4b780$7695c440$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021090823.02d578b0@127.0.0.1> <04e301c4b78d$317ffe40$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021101612.02d7f2d0@127.0.0.1> <053601c4b795$b8b9f020$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021120228.03062090@127.0.0.1> <077c01c4b7c3$d140b100$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021192544.02d7f560@127.0.0.1> <041c01c4b85c$deb1c1f0$fd529145@mtbrook.bozemanpass.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 10:30 AM 10/22/2004, David Boreham wrote: >>>Can you cite (or quote) a section from X.500 that backs up this assertion ? >> >>Though not definitive, you might also consider David >>Chadwick's "Understand X.500" >> . >>It gives some rationale as to why the ITU selected the >>(single) master copy scheme was for the Directory. If >>you want something definitive, I suggest you read X.525 and >>sections of X.501 describing the DSA Model. > >Thanks. I wasn't really looking for tutorial advice, >more a specific reference (like section so and so, subsection >whatever, where it says the following : ...). > >Surely you must be able to come up with a hard >reference to back up your assertion that multi master >replication is fundamentally incompatible with X.500 and >hence LDAP ? Yes, but since I don't see any need to rehash prior discussions regarding this fundamental aspect of X.500, I choose to offer only general references at this time. I hope we can avoid rehashing this. I think consensus is pretty clear on the matter. X.500 specifications and implementations presume that one and only one DSA is authoritative for an entry held in the Directory. However, that said, I note that this I-D may not be subjected to any IETF consensus review. It may be directly submitted to the RFC Editor. So, if folks think the X.500/LDAP specifications are not adequately clear in this area, I would suggestion that the matter be raised to the LDAPBIS WG so that they may establish consensus in this area and reflect that consensus in the revised LDAP TS. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Oct 22 16:04:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05573 for ; Fri, 22 Oct 2004 16:04:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5XB-0008CR-Fa; Fri, 22 Oct 2004 15:57:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5NP-0002Sp-BO for ldapext@megatron.ietf.org; Fri, 22 Oct 2004 15:47:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03812 for ; Fri, 22 Oct 2004 15:46:59 -0400 (EDT) Received: from [69.145.82.195] (helo=mail.montana.boreham.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL5aE-0005DZ-1b for ldapext@ietf.org; Fri, 22 Oct 2004 16:00:19 -0400 Received: from squirrel (unknown [69.145.82.218]) by mail.montana.boreham.org (Postfix) with SMTP id 72B7D1102E5 for ; Fri, 22 Oct 2004 12:46:24 -0700 (PDT) Message-ID: <080501c4b86f$cf155960$da529145@mtbrook.bozemanpass.com> From: "David Boreham" To: References: <6.1.2.0.0.20041020175617.033b0df8@127.0.0.1> <043201c4b780$7695c440$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021090823.02d578b0@127.0.0.1> <04e301c4b78d$317ffe40$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021101612.02d7f2d0@127.0.0.1> <053601c4b795$b8b9f020$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021120228.03062090@127.0.0.1> <077c01c4b7c3$d140b100$da529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041021192544.02d7f560@127.0.0.1> <041c01c4b85c$deb1c1f0$fd529145@mtbrook.bozemanpass.com> <6.1.2.0.0.20041022104451.03046470@127.0.0.1> Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt Date: Fri, 22 Oct 2004 12:46:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit > I hope we can avoid rehashing this. I think consensus is > pretty clear on the matter. X.500 specifications and > implementations presume that one and only one DSA is > authoritative for an entry held in the Directory. I see, you're really arguing from the perspective of how the service is implemented rather than any specific service semantics as seen by clients. So it's simply enough to say that MMR isn't allowed, and not important to say _why_. I get your thinking now, thanks. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Oct 22 18:23:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02970 for ; Fri, 22 Oct 2004 18:23:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6xI-0002HZ-3N; Fri, 22 Oct 2004 17:28:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6Yc-0004Un-Lx; Fri, 22 Oct 2004 17:02:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16139; Fri, 22 Oct 2004 17:02:38 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL6lR-0000Yh-Ts; Fri, 22 Oct 2004 17:15:59 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9ML261p578636; Fri, 22 Oct 2004 17:02:06 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9ML26xd244328; Fri, 22 Oct 2004 15:02:06 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9ML25xn012276; Fri, 22 Oct 2004 15:02:06 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9ML251K012267; Fri, 22 Oct 2004 15:02:05 -0600 In-Reply-To: <080501c4b86f$cf155960$da529145@mtbrook.bozemanpass.com> To: "David Boreham" MIME-Version: 1.0 Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: John McGarvey Message-ID: Date: Fri, 22 Oct 2004 17:02:04 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 10/22/2004 15:02:05, Serialize complete at 10/22/2004 15:02:05 X-Spam-Score: 0.5 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: ldapext-bounces@ietf.org, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1775978903==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a multipart message in MIME format. --===============1775978903== Content-Type: multipart/alternative; boundary="=_alternative 00720FBB85256F35_=" This is a multipart message in MIME format. --=_alternative 00720FBB85256F35_= Content-Type: text/plain; charset="US-ASCII" It is absurd to exclude multi-master replication from normal LDAP configurations. Every large deployment uses it, because they can't tolerate a single point of failure. That being the case, there is no consensus not to use it. Just the opposite: There is a consensus that it must be used. One can support multi-master replication and the increment operation. However the increment operation, and all operations on that attribute value, must occur on a particular master, and must be deferred if that master is not available. John McGarvey IBM directory architect 919-877-4892 or t/l 254-4892 "David Boreham" Sent by: ldapext-bounces@ietf.org 10/22/2004 03:46 PM To cc Subject Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt > I hope we can avoid rehashing this. I think consensus is > pretty clear on the matter. X.500 specifications and > implementations presume that one and only one DSA is > authoritative for an entry held in the Directory. I see, you're really arguing from the perspective of how the service is implemented rather than any specific service semantics as seen by clients. So it's simply enough to say that MMR isn't allowed, and not important to say _why_. I get your thinking now, thanks. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=_alternative 00720FBB85256F35_= Content-Type: text/html; charset="US-ASCII"
It is absurd to exclude multi-master replication from normal LDAP configurations.  Every large deployment uses it, because they can't tolerate a single point of failure. That being the case, there is no consensus not to use it.  Just the opposite: There is a consensus that it must be used.

One can support multi-master replication and the increment operation.  However the increment operation, and all operations on that attribute value, must occur on a particular master, and must be deferred if that master is not available.

John McGarvey
IBM directory architect
919-877-4892 or t/l 254-4892


"David Boreham" <david_list@boreham.org>
Sent by: ldapext-bounces@ietf.org

10/22/2004 03:46 PM

To
<ldapext@ietf.org>
cc
Subject
Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt





> I hope we can avoid rehashing this.  I think consensus is
> pretty clear on the matter.  X.500 specifications and
> implementations presume that one and only one DSA is
> authoritative for an entry held in the Directory.
I see, you're really arguing from the perspective
of how the service is implemented rather than any
specific service semantics as seen by clients.
So it's simply enough to say that MMR isn't allowed,
and not important to say _why_.
I get your thinking now, thanks.


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext
--=_alternative 00720FBB85256F35_=-- --===============1775978903== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============1775978903==-- From ldapext-bounces@ietf.org Fri Oct 22 19:20:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12490 for ; Fri, 22 Oct 2004 19:20:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8S6-0003Al-8E; Fri, 22 Oct 2004 19:04:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7rT-0000QY-VS for ldapext@megatron.ietf.org; Fri, 22 Oct 2004 18:26:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03747 for ; Fri, 22 Oct 2004 18:26:10 -0400 (EDT) Received: from [69.145.82.195] (helo=mail.montana.boreham.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL84K-0005wu-2g for ldapext@ietf.org; Fri, 22 Oct 2004 18:39:32 -0400 Received: from racoon (unknown [69.145.82.253]) by mail.montana.boreham.org (Postfix) with ESMTP id D82C71102E5 for ; Fri, 22 Oct 2004 15:25:34 -0700 (PDT) Message-ID: <048901c4b886$096e0470$fd529145@mtbrook.bozemanpass.com> From: "David Boreham" To: References: Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt Date: Fri, 22 Oct 2004 15:25:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit >One can support multi-master replication and the increment operation. >However the increment operation, and all operations on that attribute >value, >must occur on a particular master, and must be deferred if that master is >not available. Which (now that we're back within the realms of reality), brings me back to the question as to how clients are to know this. A client might attempt to increment an attribute of an entry when it isn't safe to do so. Should the server 'know' not to allow the operation ? Or should the client discover somehow in advance if it would be safe to do so ? Or are the 'rules' expected to be enforced administratively somehow ? _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Oct 22 19:27:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13240 for ; Fri, 22 Oct 2004 19:27:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8h7-0005At-Hx; Fri, 22 Oct 2004 19:19:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8QO-0002g2-LG for ldapext@megatron.ietf.org; Fri, 22 Oct 2004 19:02:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10222 for ; Fri, 22 Oct 2004 19:02:18 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL8dF-00087Q-Tf for ldapext@ietf.org; Fri, 22 Oct 2004 19:15:41 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9MN25Zv020924; Fri, 22 Oct 2004 23:02:06 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041022153131.0347a120@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 22 Oct 2004 16:02:41 -0700 To: John McGarvey From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt In-Reply-To: References: <080501c4b86f$cf155960$da529145@mtbrook.bozemanpass.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ldapext@ietf.org, David Boreham X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 02:02 PM 10/22/2004, John McGarvey wrote: >One can support multi-master replication and the increment operation. However the increment operation, and all operations on that attribute value, must occur on a particular master, and must be deferred if that master is not available. Yes, if you somehow are able to restrict the applications which rely on the single-master properties when updating some fragment of the DIT to a particular master in a multi-master system, then you have, in effect, a single-master system (in respect to these applications). My primary concern with the MMR extensions for LDAP proposed so far is that they simply were not truly optional [RFC2119]. It certainly is possible (some would say trivial) to design an truly optional MMR extension to LDAP. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Oct 22 20:53:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18726 for ; Fri, 22 Oct 2004 20:53:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLA8N-0002AA-BB; Fri, 22 Oct 2004 20:51:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLA5c-00007P-Tn for ldapext@megatron.ietf.org; Fri, 22 Oct 2004 20:49:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18645 for ; Fri, 22 Oct 2004 20:49:00 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLAIY-000219-2b for ldapext@ietf.org; Fri, 22 Oct 2004 21:02:22 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 22 Oct 2004 18:48:28 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Fri, 22 Oct 2004 18:48:05 -0600 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit The application of this problem to Multi-Master Replication (MMR) in general is incorrect. It should be associated with Loosely Consistent Multi-Master Replication (LCMMR). There are mechanisms which could allow for consistent MMR, thus allowing the X.500 service model to be adhered to. Furthermore, there are mechanisms which would allow even implementations of LCMMR to act in accordance with the X.500 service model when required (or conversely -- to make it truly-optional -- allow the transactional and atomicity semantics of the X.500 service model to be optionally ignored). For example, enforce that certain modifications always happen on a predetermined master, but allow that behavior to be optionally overridden. Note that neither of these points means that the incr I-D (or any other I-D) needs to consider the problems introduced by LCMMR. It would be the job of a LCMMR specification to state these problems (and possible solutions). Mostly, I dislike it when messages end up demonizing MMR in a general way, and wanted to clarify the points above. Jim >>> "Kurt D. Zeilenga" 10/21/04 1:49:11 PM >>> At 10:45 AM 10/21/2004, David Boreham wrote: >>In LDAP, clients may presume server is acting in accordance >>with the X.500 data model. If the server is unable or >>unwilling to do that, then it should not provide service. > >I see, I think you've answered my question: this >feaure should not be implemented by servers that >are participating in a multimaster replication mechanism >with respect to the entry being modified (unless the >server does something unusual to deliver the >required consistency guarantees such as using 2-phase >commit). It's my view that servers which are 'participating in a multimaster replication mechanism' are not LDAP servers. LDAP servers, aside from communicating using LDAP PDUs, act in accordance with X.500. While the servers you refer might communicate using LDAP PDUs, they are not acting in accordance with X.500 and hence, in my view, are not LDAP servers. >It might be worth noting this in the draft, for those >who might ask this question in the future. I think its sufficient to specify that LDAP servers are to act in accordance with X.500. This I-D does so by incorporating [Roadmap]. That said, I think it would be good to note to the community the harm that truly non-optional introduction of MMR might have on existing directory applications, to reiterate to implementors that LDAP servers are to act in accordance with X.500, and encourage those who desire a different service model to design and specify a system that offers it. That system could be based on LDAP, but if so, it should engineered as a truly optional extension to LDAP. (For those who don't grok the terms "truly optional" or "truly non-optional", I refer you to discussion of the "MAY" keyword in RFC 2119). Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Sun Oct 24 01:46:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18159 for ; Sun, 24 Oct 2004 01:46:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLb8n-0006hf-FE; Sun, 24 Oct 2004 01:42:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLb2g-00062S-KU for ldapext@megatron.ietf.org; Sun, 24 Oct 2004 01:36:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17870 for ; Sun, 24 Oct 2004 01:35:30 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLbFc-00039Q-Bo for ldapext@ietf.org; Sun, 24 Oct 2004 01:49:09 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Sat, 23 Oct 2004 23:34:57 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Sat, 23 Oct 2004 23:34:36 -0600 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] Re: Password Policy for LDAP Directories Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: ldapext@ietf.org, gabriele.garuglieri@infoblu.it X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0136714956==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0136714956== Content-Type: multipart/alternative; boundary="=__Part90B0A7FC.2__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part90B0A7FC.2__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I believe the intent (however wrongly formulated) was to allow the user to receive a warning no matter what. Even if the password's max age has passed, the user would be allowed pwdExpireWarning seconds to change the pwd. The definition of pwdExpireWarning talks about this in a not very precise way (The number of seconds before the password will expire after the user is first warned of its upcoming expiration.) Some history to help make sense of things: The password policy I-D was created as a blend of the (then) Netscape and Novell directory password policies. I believe the original implementors of pwdExpireWarning (Netscape) used this to both warn of expiration, and also allow some kind of grace login period. Novell's implementation didn't include the notion of a warning period. Only a number of grace logins. So now we have two ways of achieving 'grace login'. A better way of specifying the pwdExpireWarning and pwdMaxAge concepts would have been to use one attribute to specify an age at which an expiration warning is sent, and another attribute specified how long these warnings will continue before the password finally expires. I dislike having two similar but different grace mechanisms, so I propose that we remove pwdExpireWarned, and expire the password when it reaches pwdMaxAge (regardless of whether any warnings have been sent). I'll update the I-D to reflect this without debate (because the deadline is so near), and we can go from there. Jim >>> Andrew Sciberras 9/14/04 7:48:25 PM >>> Hi Niel, Neil Dunbar wrote: > The pwdMaxAge should be the absolute maximum time that the password can > be used by anyone as a credential. The pwdExpirationWarning time, I > think, should be the earliest opportunity that the directory server can > warn the user that his/her password is approaching expiry. If the user > comes into the expiry period late in the game - tough. You can always > use the grace logins feature to allow the user with the dud password to > change it after it has ceased to be a meaningful credential for general > directory operations If someone was to implement the draft in its current form, their first warning time would indicate the time difference between the current time and the time that the password is due to expire. Subsequent logins would result in a warning time that will go beyond the specified pwdMaxAge allowing the user to receive their full warning period. Our implementation, which was based around the -05 version of the draft handled this inconsistency by returning an initial warning message of pwdExpireWarning. I've now noticed, in version -07 of the draft, that the following new line exists within the description of pwdExpireWarning: If not 0, the value must be smaller than the value of the pwdMaxAge attribute. This seriously implies that the author's intention is to ensure that the warning time does not exceed the maximum age of the password. I'm not extremely passionate about whether a user should receive their full warning period. Some consensus on this issue, and the author's opinion (Jim?) would be good though. Andrew Sciberras eB2Bcom - Software Engineer --=__Part90B0A7FC.2__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I believe the intent (however wrongly formulated) was to allow the = user to receive a warning no matter what. Even if the password's max age = has passed, the user would be allowed pwdExpireWarning seconds to change = the pwd. The definition of pwdExpireWarning talks about this in a not very = precise way (The number of seconds before the password will expire after = the user is first warned of its upcoming expiration.)
 
Some history to help make sense of things:
 
The password policy I-D was created as a blend of the (then) Netscape = and Novell directory password policies.
 
I believe the original implementors of pwdExpireWarning (Netscape) = used this to both warn of expiration, and also allow some kind of grace = login period.
Novell's implementation didn't include the notion of a warning = period. Only a number of grace logins.
 
So now we have two ways of achieving 'grace login'.
 
A better way of specifying the pwdExpireWarning and pwdMaxAge = concepts would have been to use one attribute to specify an age at = which an expiration warning is sent, and another attribute specified how = long these warnings will continue before the password finally expires.
 
I dislike having two similar but different grace mechanisms, so I = propose that we remove pwdExpireWarned, and expire the password when it = reaches pwdMaxAge (regardless of whether any warnings have been sent).
 
I'll update the I-D to reflect this without debate (because the = deadline is so near), and we can go from there.
 
Jim

>>> Andrew Sciberras <andrew.sciberras@eB2Bcom.com>= 9/14/04 7:48:25 PM >>>
Hi Niel,


Neil Dunbar = wrote:
<SNIP>
> The pwdMaxAge should be the absolute = maximum time that the password can
> be used by anyone as a = credential. The pwdExpirationWarning time, I
> think, should be the = earliest opportunity that the directory server can
> warn the user = that his/her password is approaching expiry. If the user
> comes = into the expiry period late in the game - tough. You can always
> = use the grace logins feature to allow the user with the dud password = to
> change it after it has ceased to be a meaningful credential for = general
> directory operations
</SNIP>


If = someone was to implement the draft in its current form, their first =
warning time would indicate the time difference between the current = time
and the time that the password is due to expire. Subsequent = logins would
result in a warning time that will go beyond the = specified pwdMaxAge
allowing the user to receive their full warning = period.

Our implementation, which was based around the -05 version = of the draft
handled this inconsistency by returning an initial = warning message of
pwdExpireWarning.

I've now noticed, in = version -07 of the draft, that the following new
line exists within = the description of pwdExpireWarning:
If not 0, the value must be = smaller than the value of the pwdMaxAge
attribute.

This = seriously implies that the author's intention is to ensure that the =
warning time does not exceed the maximum age of the password.

I'= m not extremely passionate about whether a user should receive their =
full warning period. Some consensus on this issue, and the author's =
opinion (Jim?) would be good though.


Andrew Sciberras
eB2= Bcom - Software Engineer
--=__Part90B0A7FC.2__=-- --===============0136714956== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0136714956==-- From ldapext-bounces@ietf.org Sun Oct 24 15:21:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24156 for ; Sun, 24 Oct 2004 15:21:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLntz-0007AT-GI; Sun, 24 Oct 2004 15:19:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLnt9-0006gK-Vj for ldapext@megatron.ietf.org; Sun, 24 Oct 2004 15:18:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23866 for ; Sun, 24 Oct 2004 15:18:46 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLo6S-0003UW-9f for ldapext@ietf.org; Sun, 24 Oct 2004 15:32:32 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Sun, 24 Oct 2004 13:18:16 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Sun, 24 Oct 2004 13:17:56 -0600 From: "Jim Sermersheim" To: , Subject: replicating timestamps/counters (was: Re: [ldapext] Re: draft-behera-ldap-password-policy-07.txt) Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: ldapext@ietf.org, hyc@highlandsun.com X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1469805363==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============1469805363== Content-Type: multipart/alternative; boundary="=__Part59796EF4.1__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part59796EF4.1__= Content-Type: text/plain; charset=Windows-1256 Content-Transfer-Encoding: quoted-printable Regarding this thread, I currently agree with Kurt's final paragraph. I = propose we leave the values in question (pwdFailureTime and pwdGraceUseTime= ) as GeneralizedTime syntax (and not switch to CSN syntax). =20 After reviewing the thread, I believe GeneralizedTime is capable of being = used to populate unique, incrementing values of an attribute (whether = replicated in a loosly consistent way or not). =20 For example, two servers in a loosly consistent replication agreement = could either: a) agree to use portions of the fractional seconds field to hold something = akin to a 'replica ID' b) agree to contact a single authoritative source for the generation of = timestamps. =20 This also works fine for a single server system where (as Howard first = mentioned) operations are happening faster than the system's timestamps = could increment. A global function which generates unique timestamps would = be a fairly trivial mechanism to solve this. =20 That said, I have a sneaking suspicion that I'm overlooking something * = otherwise, why all the fuss with CSN syntax (in general) to begin with? = Why not just abuse the fractional seconds of Generalized Time? =20 Jim >>> "Kurt D. Zeilenga" 3/16/04 11:38:46 AM >>> At 08:17 AM 3/16/2004, Ludovic Poitou wrote: >> Also, doesn't this mean you can >>attack all the shadows at will until the master communicates >>that the account is locked? >>=20 >That is an implementation issue (one can apply the change locally and = communicate it to the Master).=20 Doesn't this go against your' user's desire to have a strict lock out on N retries policy across the service? I mean, if implementations are free to local retries counts, than cannot those be abused to get retries than the policy allowed? Ignoring DoS attacks in this area, is there a scaling problem here? We have deployments involving large numbers of replicas where maintain policy state information on a context wide basis would be prohibitively expensive. It seems to me that it would be better to define any state information to be DSA-specific, but with a comment saying that DSAs may agree to share state information but that the how to that sharing could be performed is beyond the scope of this document. Kurt=20 --=__Part59796EF4.1__= Content-Type: text/html; charset=Windows-1256 Content-Transfer-Encoding: quoted-printable
Regarding this thread, I currently agree with Kurt's final paragraph. = I propose we leave the values in question (pwdFailureTime and pwdGraceUseTi= me) as GeneralizedTime syntax (and not switch to CSN syntax).
 
After reviewing the thread, I believe GeneralizedTime is capable of = being used to populate unique, incrementing values of an attribute = (whether replicated in a loosly consistent way or not).
 
For example, two servers in a loosly consistent replication agreement = could either:
a) agree to use portions of the fractional seconds field to hold = something akin to a 'replica ID'
b) agree to contact a single authoritative source for the generation = of timestamps.
 
This also works fine for a single server system where (as Howard = first mentioned) operations are happening faster than the system's = timestamps could increment. A global function which generates unique = timestamps would be a fairly trivial mechanism to solve this.
 
That said, I have a sneaking suspicion that I'm overlooking something = =97 otherwise, why all the fuss with CSN syntax (in general) to begin = with? Why not just abuse the fractional seconds of Generalized Time?
 
Jim

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> = 3/16/04 11:38:46 AM >>>
At 08:17 AM 3/16/2004, Ludovic Poitou = wrote:
>> Also, doesn't this mean you can
>>attack all = the shadows at will until the master communicates
>>that the = account is locked?
>>
>That is an implementation issue = (one can apply the change locally and communicate it to the Master). =

Doesn't this go against your' user's desire to have a strict
loc= k out on N retries policy across the service? I mean, if
implementations= are free to local retries counts, than cannot
those be abused to get = retries than the policy allowed?

Ignoring DoS attacks in this area, = is there a scaling problem
here?

We have deployments involving = large numbers of replicas
where maintain policy state information on a = context
wide basis would be prohibitively expensive.

It seems to = me that it would be better to define any state
information to be = DSA-specific, but with a comment saying
that DSAs may agree to share = state information but that
the how to that sharing could be performed = is beyond the
scope of this document.

Kurt

<= /HTML> --=__Part59796EF4.1__=-- --===============1469805363== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============1469805363==-- From ldapext-bounces@ietf.org Mon Oct 25 06:15:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10017 for ; Mon, 25 Oct 2004 06:15:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM1qR-0006No-R3; Mon, 25 Oct 2004 06:12:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM1or-0005mQ-EN for ldapext@megatron.ietf.org; Mon, 25 Oct 2004 06:11:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09659 for ; Mon, 25 Oct 2004 06:11:14 -0400 (EDT) Received: from gort.hpl.hp.com ([192.6.10.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM22G-0002ht-UZ for ldapext@ietf.org; Mon, 25 Oct 2004 06:25:10 -0400 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by gort.hpl.hp.com (8.12.10/8.12.10) with ESMTP id i9PAAoj3015604; Mon, 25 Oct 2004 11:10:51 +0100 (BST) Received: from dunbar-n-1.hpl.hp.com (dunbar-n-1.hpl.hp.com [15.144.26.129]) by otter.hpl.hp.com (8.9.3 (PHNE_25183+JAGae58098)/HP-Labs Bristol Internal Mail Hub) with ESMTP id LAA11256; Mon, 25 Oct 2004 11:10:48 +0100 (BST) Subject: Re: [ldapext] Re: Password Policy for LDAP Directories From: Neil Dunbar To: Jim Sermersheim In-Reply-To: References: Content-Type: text/plain Organization: Managed Directories, MSGD, HP Services Date: Mon, 25 Oct 2004 11:10:26 +0100 Message-Id: <1098699026.7585.13.camel@dunbar-n-1.hpl.hp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit X-HPL-MailScanner-Information: Please contact the Helpdesk for more information X-HPL-MailScanner: Found to be clean X-HPL-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-1.403, required 5, autolearn=not spam, ALL_TRUSTED -0.84, AWL -0.56) X-MailScanner-From: neil.dunbar@hp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: andrew.sciberras@eB2Bcom.com, ldapext@ietf.org, gabriele.garuglieri@infoblu.it X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit On Sat, 2004-10-23 at 23:34 -0600, Jim Sermersheim wrote: > I dislike having two similar but different grace mechanisms, so I > propose that we remove pwdExpireWarned, and expire the password when > it reaches pwdMaxAge (regardless of whether any warnings have been > sent). > I'll update the I-D to reflect this without debate (because the > deadline is so near), and we can go from there. Sounds good to me. Thanks for the history lesson, Jim - explains a lot. Neil _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Oct 25 12:22:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11283 for ; Mon, 25 Oct 2004 12:22:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM7P7-00020e-0u; Mon, 25 Oct 2004 12:09:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM7Ln-0000uD-QU for ldapext@megatron.ietf.org; Mon, 25 Oct 2004 12:05:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09275 for ; Mon, 25 Oct 2004 12:05:36 -0400 (EDT) Received: from e2.ny.us.ibm.com ([32.97.182.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM7ZG-0001eG-PO for ldapext@ietf.org; Mon, 25 Oct 2004 12:19:35 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9PG57BF420816; Mon, 25 Oct 2004 12:05:07 -0400 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9PG568w278820; Mon, 25 Oct 2004 12:05:06 -0400 In-Reply-To: Subject: Re: [ldapext] Re: Password Policy for LDAP Directories To: "Jim Sermersheim" X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: John McMeeking Date: Mon, 25 Oct 2004 11:05:04 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V70_M2_07222004 Beta 2|July 22, 2004) at 10/25/2004 11:05:06 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Sounds good to me. John McMeeking ldapext-bounces@ietf.org wrote on 10/24/2004 12:34:36 AM: > I believe the intent (however wrongly formulated) was to allow the > user to receive a warning no matter what. Even if the password's max > age has passed, the user would be allowed pwdExpireWarning seconds > to change the pwd. The definition of pwdExpireWarning talks about > this in a not very precise way (The number of seconds before the > password will expire after the user is first warned of its upcoming > expiration.) > > Some history to help make sense of things: > > The password policy I-D was created as a blend of the (then) > Netscape and Novell directory password policies. > > I believe the original implementors of pwdExpireWarning (Netscape) > used this to both warn of expiration, and also allow some kind of > grace login period. > Novell's implementation didn't include the notion of a warning > period. Only a number of grace logins. > > So now we have two ways of achieving 'grace login'. > > A better way of specifying the pwdExpireWarning and pwdMaxAge > concepts would have been to use one attribute to specify an age at > which an expiration warning is sent, and another attribute specified > how long these warnings will continue before the password finally expires. > > I dislike having two similar but different grace mechanisms, so I > propose that we remove pwdExpireWarned, and expire the password when > it reaches pwdMaxAge (regardless of whether any warnings have been sent). > > I'll update the I-D to reflect this without debate (because the > deadline is so near), and we can go from there. > > Jim > > >>> Andrew Sciberras 9/14/04 7:48:25 PM >>> > Hi Niel, > > > Neil Dunbar wrote: > > > The pwdMaxAge should be the absolute maximum time that the password can > > be used by anyone as a credential. The pwdExpirationWarning time, I > > think, should be the earliest opportunity that the directory server can > > warn the user that his/her password is approaching expiry. If the user > > comes into the expiry period late in the game - tough. You can always > > use the grace logins feature to allow the user with the dud password to > > change it after it has ceased to be a meaningful credential for general > > directory operations > > > > If someone was to implement the draft in its current form, their first > warning time would indicate the time difference between the current time > and the time that the password is due to expire. Subsequent logins would > result in a warning time that will go beyond the specified pwdMaxAge > allowing the user to receive their full warning period. > > Our implementation, which was based around the -05 version of the draft > handled this inconsistency by returning an initial warning message of > pwdExpireWarning. > > I've now noticed, in version -07 of the draft, that the following new > line exists within the description of pwdExpireWarning: > If not 0, the value must be smaller than the value of the pwdMaxAge > attribute. > > This seriously implies that the author's intention is to ensure that the > warning time does not exceed the maximum age of the password. > > I'm not extremely passionate about whether a user should receive their > full warning period. Some consensus on this issue, and the author's > opinion (Jim?) would be good though. > > > Andrew Sciberras > eB2Bcom - Software Engineer_______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Oct 25 19:56:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20441 for ; Mon, 25 Oct 2004 19:56:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEPv-0002Hz-H8; Mon, 25 Oct 2004 19:38:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMCX5-0001g3-0h for ldapext@megatron.ietf.org; Mon, 25 Oct 2004 17:37:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16412 for ; Mon, 25 Oct 2004 17:37:35 -0400 (EDT) Received: from amos.eb2b.com.au ([210.8.191.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMCkZ-0002yd-Kx for ldapext@ietf.org; Mon, 25 Oct 2004 17:51:37 -0400 Received: from [192.168.1.155] (210.8.191.250) by amos.eb2b.com.au (7.1.016.1) (authenticated as andrew.sciberras) id 416CAD3800001486; Tue, 26 Oct 2004 07:46:19 +1000 Message-ID: <417D71D3.9050606@eB2Bcom.com> Date: Tue, 26 Oct 2004 07:36:19 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-au, en-gb, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Re: Password Policy for LDAP Directories References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org, gabriele.garuglieri@infoblu.it X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew.sciberras@eB2Bcom.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit G'Day I'm generally satisfied with this. If any directories exist today that use the following model: * pwdMaxAge - Absolute maximum age of the password * pwdExpireWarning - Time period before the max age in which warnings will be delivered, Then changing the semantics of these attributes would lead to unexpected behavior if an organization upgraded their directory server to the new functionality. Eg. A directory that wants to warn people 6 months before their password is due to expire. pwdMaxAge = 31536000 (1 year) pwdExpireWarning = 15768000 (6 Months) Updating the directory server to one that supports Jim's suggestion below will result in the password reaching its max age, then remaining valid for another 6 months. I'm not too sure if this is likely to be a serious problem for implementations, but some text in the security considerations of the draft indicating this might be appropriate. Cheers _________________________________________ Andrew Sciberras eB2Bcom - Software Engineer Jim Sermersheim wrote: > I believe the intent (however wrongly formulated) was to allow the user > to receive a warning no matter what. Even if the password's max age has > passed, the user would be allowed pwdExpireWarning seconds to change the > pwd. The definition of pwdExpireWarning talks about this in a not very > precise way (The number of seconds before the password will expire after > the user is first warned of its upcoming expiration.) > > Some history to help make sense of things: > > The password policy I-D was created as a blend of the (then) Netscape > and Novell directory password policies. > > I believe the original implementors of pwdExpireWarning (Netscape) used > this to both warn of expiration, and also allow some kind of grace login > period. > Novell's implementation didn't include the notion of a warning period. > Only a number of grace logins. > > So now we have two ways of achieving 'grace login'. > > A better way of specifying the pwdExpireWarning and pwdMaxAge concepts > would have been to use one attribute to specify an age at which an > expiration warning is sent, and another attribute specified how long > these warnings will continue before the password finally expires. > > I dislike having two similar but different grace mechanisms, so I > propose that we remove pwdExpireWarned, and expire the password when it > reaches pwdMaxAge (regardless of whether any warnings have been sent). > > I'll update the I-D to reflect this without debate (because the > deadline is so near), and we can go from there. > > Jim > > >>>>Andrew Sciberras 9/14/04 7:48:25 PM >>>> > > Hi Niel, > > > Neil Dunbar wrote: > > >>The pwdMaxAge should be the absolute maximum time that the password > > can > >>be used by anyone as a credential. The pwdExpirationWarning time, I >>think, should be the earliest opportunity that the directory server > > can > >>warn the user that his/her password is approaching expiry. If the > > user > >>comes into the expiry period late in the game - tough. You can > > always > >>use the grace logins feature to allow the user with the dud password > > to > >>change it after it has ceased to be a meaningful credential for > > general > >>directory operations > > > > > If someone was to implement the draft in its current form, their first > > warning time would indicate the time difference between the current > time > and the time that the password is due to expire. Subsequent logins > would > result in a warning time that will go beyond the specified pwdMaxAge > allowing the user to receive their full warning period. > > Our implementation, which was based around the -05 version of the draft > > handled this inconsistency by returning an initial warning message of > pwdExpireWarning. > > I've now noticed, in version -07 of the draft, that the following new > line exists within the description of pwdExpireWarning: > If not 0, the value must be smaller than the value of the pwdMaxAge > attribute. > > This seriously implies that the author's intention is to ensure that > the > warning time does not exceed the maximum age of the password. > > I'm not extremely passionate about whether a user should receive their > > full warning period. Some consensus on this issue, and the author's > opinion (Jim?) would be good though. > > > Andrew Sciberras > eB2Bcom - Software Engineer > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Oct 25 20:07:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21944 for ; Mon, 25 Oct 2004 20:07:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEWS-0004Qq-81; Mon, 25 Oct 2004 19:45:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMDkC-0005wq-QA for ldapext@megatron.ietf.org; Mon, 25 Oct 2004 18:55:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07040 for ; Mon, 25 Oct 2004 18:55:13 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMDxj-0000ae-Q4 for ldapext@ietf.org; Mon, 25 Oct 2004 19:09:16 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 25 Oct 2004 16:54:42 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Mon, 25 Oct 2004 16:54:23 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartDFFFEE0F.0__=" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Subject: [ldapext] Fwd: I-D ACTION:draft-behera-ldap-password-policy-08.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartDFFFEE0F.0__= Content-Type: multipart/alternative; boundary="=__PartDFFFEE0F.1__=" --=__PartDFFFEE0F.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This update addresses some but not all concerns received to date. I have 68 remaining mails left to get through. Jim >>> 10/25/04 1:58:46 PM >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. Title: Password Policy for LDAP Directories Author(s): P. Behera, et al. Filename: draft-behera-ldap-password-policy-08.txt Pages: 38 Date: 2004-10-25 Password policy as described in this document is a set of rules that controls how passwords are used and administered in LDAP directories. In order to improve the security of LDAP directories and make it difficult for password cracking programs to break into directories, it is desirable to enforce a set of rules on password usage. These rules are made to ensure that users change their passwords periodically, passwords meet construction requirements, the re-use of old password is restricted, and users are locked out after a certain number of failed attempts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-behera-ldap-password-policy-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org . In the body type: "FILE /internet-drafts/draft-behera-ldap-password-policy-08.txt". NOTE:The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --=__PartDFFFEE0F.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This update addresses some but not all concerns received to date. I = have 68 remaining mails left to get through.
 
Jim

>>> <Internet-Drafts@ietf.org> 10/25/04 = 1:58:46 PM >>>
A New Internet-Draft is available from the = on-line Internet-Drafts directories.


Title: Password Policy for = LDAP Directories
Author(s): P. Behera, et al.
Filename: draft-behera-= ldap-password-policy-08.txt
Pages: 38
Date: 2004-10-25

Passwor= d policy as described in this document is a set of rules that
controls = how passwords are used and administered in LDAP
directories. In order = to improve the security of LDAP directories
and make it difficult for = password cracking programs to break into
directories, it is desirable = to enforce a set of rules on password
usage. These rules are made to = ensure that users change their
passwords periodically, passwords meet = construction requirements,
the re-use of old password is restricted, = and users are locked out
after a certain number of failed attempts.
<= BR>A URL for this Internet-Draft is:
http://www.ietf.or= g/internet-drafts/draft-behera-ldap-password-policy-08.txt =

To remove yourself from the I-D Announcement list, send a message = to
i-d-announce-req= uest@ietf.org with the word unsubscribe in the body of the = message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=
to change your subscription settings.


Internet-Draf= ts are also available by anonymous FTP. Login with the username
"anonymo= us" and a password of your e-mail address. After logging in,
type "cd = internet-drafts" and then
"get draft-behera-ldap-password-policy-08.txt"= .

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Dr= afts can also be obtained by e-mail.

Send a message to:
mailserv@ietf.org .
In the = body type:
"FILE /internet-drafts/draft-behera-ldap-password-policy-08.t= xt".

NOTE:The mail server at ietf.org can return the document = in
MIME-encoded form by using the "mpack" utility. To use this
featur= e, insert the command "ENCODING mime" before the "FILE"
command. To = decode the response(s), you will need "munpack" or
a MIME-compliant = mail reader. Different MIME-compliant mail readers
exhibit different = behavior, especially when dealing with
"multipart" MIME messages (i.e. = documents which have been split
up into multiple messages), so check = your local documentation on
how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implem= entation to automatically retrieve the ASCII version of the
Internet-Dra= ft.
--=__PartDFFFEE0F.1__=-- --=__PartDFFFEE0F.0__= Content-Type: application/octet-stream; name="Part.001" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Part.001" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNC0xMC0yNTE2MTkzNS5J LURAaWV0Zi5vcmc+DQoNCkVOQ09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1iZWhlcmEtbGRhcC1wYXNzd29yZC1wb2xpY3ktMDgudHh0DQo= --=__PartDFFFEE0F.0__= Content-Type: text/plain; name="draft-behera-ldap-password-policy-08.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="draft-behera-ldap-password-policy-08.txt" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Content-Type: text/plain Content-ID: <2004-10-25161935.I-D@ietf.org> --=__PartDFFFEE0F.0__= Content-Type: application/octet-stream; name="Part.003" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Part.003" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= --=__PartDFFFEE0F.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__PartDFFFEE0F.0__=-- From ldapext-bounces@ietf.org Mon Oct 25 20:22:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23787 for ; Mon, 25 Oct 2004 20:22:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMF0d-0004T5-2o; Mon, 25 Oct 2004 20:16:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEtp-0001Rg-12 for ldapext@megatron.ietf.org; Mon, 25 Oct 2004 20:09:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22273 for ; Mon, 25 Oct 2004 20:09:15 -0400 (EDT) Received: from amos.eb2b.com.au ([210.8.191.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMF7J-0005DR-Ii for ldapext@ietf.org; Mon, 25 Oct 2004 20:23:17 -0400 Received: from [192.168.1.155] (210.8.191.250) by amos.eb2b.com.au (7.1.016.1) (authenticated as andrew.sciberras) id 416CAD38000014F7; Tue, 26 Oct 2004 10:18:04 +1000 Message-ID: <417D9565.5060607@eB2Bcom.com> Date: Tue, 26 Oct 2004 10:08:05 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-au, en-gb, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Re: Password Policy for LDAP Directories References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org, gabriele.garuglieri@infoblu.it X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew.sciberras@eB2Bcom.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Sorry Jim... I see where your coming from now :) Yep I agree. Andrew. Jim Sermersheim wrote: > Actually, I suggested that the password expire at its max age (regardles > of whether any warnings have been sent). > > Jim > > >>>>Andrew Sciberras 10/25/04 3:36:19 PM >>>> > > G'Day > > I'm generally satisfied with this. > > If any directories exist today that use the following model: > * pwdMaxAge - Absolute maximum age of the password > * pwdExpireWarning - Time period before the max age in which warnings > will be delivered, > > Then changing the semantics of these attributes would lead to > unexpected > behavior if an organization upgraded their directory server to the new > > functionality. > > Eg. A directory that wants to warn people 6 months before their > password > is due to expire. > pwdMaxAge = 31536000 (1 year) > pwdExpireWarning = 15768000 (6 Months) > > Updating the directory server to one that supports Jim's suggestion > below will result in the password reaching its max age, then remaining > > valid for another 6 months. > > > I'm not too sure if this is likely to be a serious problem for > implementations, but some text in the security considerations of the > draft indicating this might be appropriate. > > Cheers > _________________________________________ > Andrew Sciberras > eB2Bcom - Software Engineer > > > Jim Sermersheim wrote: > > >>I believe the intent (however wrongly formulated) was to allow the > > user > >>to receive a warning no matter what. Even if the password's max age > > has > >>passed, the user would be allowed pwdExpireWarning seconds to change > > the > >>pwd. The definition of pwdExpireWarning talks about this in a not > > very > >>precise way (The number of seconds before the password will expire > > after > >>the user is first warned of its upcoming expiration.) >> >>Some history to help make sense of things: >> >>The password policy I-D was created as a blend of the (then) > > Netscape > >>and Novell directory password policies. >> >>I believe the original implementors of pwdExpireWarning (Netscape) > > used > >>this to both warn of expiration, and also allow some kind of grace > > login > >>period. >>Novell's implementation didn't include the notion of a warning > > period. > >>Only a number of grace logins. >> >>So now we have two ways of achieving 'grace login'. >> >>A better way of specifying the pwdExpireWarning and pwdMaxAge > > concepts > >>would have been to use one attribute to specify an age at which an >>expiration warning is sent, and another attribute specified how long >>these warnings will continue before the password finally expires. >> >>I dislike having two similar but different grace mechanisms, so I >>propose that we remove pwdExpireWarned, and expire the password when > > it > >>reaches pwdMaxAge (regardless of whether any warnings have been > > sent). > >>I'll update the I-D to reflect this without debate (because the >>deadline is so near), and we can go from there. >> >>Jim >> >> >> >>>>>Andrew Sciberras < andrew.sciberras@eB2Bcom.com > 9/14/04 7:48:25 > > PM > >>Hi Niel, >> >> >>Neil Dunbar wrote: >> >> >>>The pwdMaxAge should be the absolute maximum time that the password >> >>can >> >> >>>be used by anyone as a credential. The pwdExpirationWarning time, I >>>think, should be the earliest opportunity that the directory server >> >>can >> >> >>>warn the user that his/her password is approaching expiry. If the >> >>user >> >> >>>comes into the expiry period late in the game - tough. You can >> >>always >> >> >>>use the grace logins feature to allow the user with the dud password >> >>to >> >> >>>change it after it has ceased to be a meaningful credential for >> >>general >> >> >>>directory operations >> >> >> >> >>If someone was to implement the draft in its current form, their > > first > >>warning time would indicate the time difference between the current >>time >>and the time that the password is due to expire. Subsequent logins >>would >>result in a warning time that will go beyond the specified pwdMaxAge > > >>allowing the user to receive their full warning period. >> >>Our implementation, which was based around the -05 version of the > > draft > >>handled this inconsistency by returning an initial warning message of > > >>pwdExpireWarning. >> >>I've now noticed, in version -07 of the draft, that the following new > > >>line exists within the description of pwdExpireWarning: >>If not 0, the value must be smaller than the value of the pwdMaxAge >>attribute. >> >>This seriously implies that the author's intention is to ensure that >>the >>warning time does not exceed the maximum age of the password. >> >>I'm not extremely passionate about whether a user should receive > > their > >>full warning period. Some consensus on this issue, and the author's >>opinion (Jim?) would be good though. >> >> >>Andrew Sciberras >>eB2Bcom - Software Engineer >> >> >> >> >> > > ------------------------------------------------------------------------ > >>_______________________________________________ >>Ldapext mailing list >>Ldapext@ietf.org >>https://www1.ietf.org/mailman/listinfo/ldapext > > > > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Oct 25 20:47:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25722 for ; Mon, 25 Oct 2004 20:47:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMFTU-0004dg-KM; Mon, 25 Oct 2004 20:46:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMFS8-0004EA-NK for ldapext@megatron.ietf.org; Mon, 25 Oct 2004 20:44:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25454 for ; Mon, 25 Oct 2004 20:44:42 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMFfg-0005uc-EW for ldapext@ietf.org; Mon, 25 Oct 2004 20:58:45 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 25 Oct 2004 18:44:12 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Mon, 25 Oct 2004 18:43:49 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73948e4d005645343fd08e813e5615ef Subject: [ldapext] Password Policy OIDs X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1617627559==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============1617627559== Content-Type: multipart/alternative; boundary="=__Part1C3C2DD5.0__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part1C3C2DD5.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This does bring up another point I wanted to discuss though... This draft was written way back when it was popular to assign OIDs in I-D's. A practice that has lost favor partly due to implementations using those OIDs and experiencing problems as semantics changed but OIDs didn't. I'd like to move this I-D forward, and I don't want to be tied to any semantics defined in previous versions. I propose that we replace the existing OIDs with requests for IANA OIDs. This way, existing implementations won't appear to be invalid according to the current and future revisions, and I won't have to worry so much about breaking existing implementations. What do other's think? Jim >>> Andrew Sciberras 10/25/04 6:08:05 PM >>> Sorry Jim... I see where your coming from now :) Yep I agree. Andrew. Jim Sermersheim wrote: > Actually, I suggested that the password expire at its max age (regardles > of whether any warnings have been sent). > > Jim > > >>>>Andrew Sciberras < andrew.sciberras@eB2Bcom.com > 10/25/04 3:36:19 PM >>>> > > G'Day > > I'm generally satisfied with this. > > If any directories exist today that use the following model: > * pwdMaxAge - Absolute maximum age of the password > * pwdExpireWarning - Time period before the max age in which warnings > will be delivered, > > Then changing the semantics of these attributes would lead to > unexpected > behavior if an organization upgraded their directory server to the new > > functionality. > > Eg. A directory that wants to warn people 6 months before their > password > is due to expire. > pwdMaxAge = 31536000 (1 year) > pwdExpireWarning = 15768000 (6 Months) > > Updating the directory server to one that supports Jim's suggestion > below will result in the password reaching its max age, then remaining > > valid for another 6 months. > > > I'm not too sure if this is likely to be a serious problem for > implementations, but some text in the security considerations of the > draft indicating this might be appropriate. > > Cheers > _________________________________________ > Andrew Sciberras > eB2Bcom - Software Engineer > > > Jim Sermersheim wrote: > > >>I believe the intent (however wrongly formulated) was to allow the > > user > >>to receive a warning no matter what. Even if the password's max age > > has > >>passed, the user would be allowed pwdExpireWarning seconds to change > > the > >>pwd. The definition of pwdExpireWarning talks about this in a not > > very > >>precise way (The number of seconds before the password will expire > > after > >>the user is first warned of its upcoming expiration.) >> >>Some history to help make sense of things: >> >>The password policy I-D was created as a blend of the (then) > > Netscape > >>and Novell directory password policies. >> >>I believe the original implementors of pwdExpireWarning (Netscape) > > used > >>this to both warn of expiration, and also allow some kind of grace > > login > >>period. >>Novell's implementation didn't include the notion of a warning > > period. > >>Only a number of grace logins. >> >>So now we have two ways of achieving 'grace login'. >> >>A better way of specifying the pwdExpireWarning and pwdMaxAge > > concepts > >>would have been to use one attribute to specify an age at which an >>expiration warning is sent, and another attribute specified how long >>these warnings will continue before the password finally expires. >> >>I dislike having two similar but different grace mechanisms, so I >>propose that we remove pwdExpireWarned, and expire the password when > > it > >>reaches pwdMaxAge (regardless of whether any warnings have been > > sent). > >>I'll update the I-D to reflect this without debate (because the >>deadline is so near), and we can go from there. >> >>Jim >> >> >> >>>>>Andrew Sciberras < andrew.sciberras@eB2Bcom.com > 9/14/04 7:48:25 > > PM > >>Hi Niel, >> >> >>Neil Dunbar wrote: >> >> >>>The pwdMaxAge should be the absolute maximum time that the password >> >>can >> >> >>>be used by anyone as a credential. The pwdExpirationWarning time, I >>>think, should be the earliest opportunity that the directory server >> >>can >> >> >>>warn the user that his/her password is approaching expiry. If the >> >>user >> >> >>>comes into the expiry period late in the game - tough. You can >> >>always >> >> >>>use the grace logins feature to allow the user with the dud password >> >>to >> >> >>>change it after it has ceased to be a meaningful credential for >> >>general >> >> >>>directory operations >> >> >> >> >>If someone was to implement the draft in its current form, their > > first > >>warning time would indicate the time difference between the current >>time >>and the time that the password is due to expire. Subsequent logins >>would >>result in a warning time that will go beyond the specified pwdMaxAge > > >>allowing the user to receive their full warning period. >> >>Our implementation, which was based around the -05 version of the > > draft > >>handled this inconsistency by returning an initial warning message of > > >>pwdExpireWarning. >> >>I've now noticed, in version -07 of the draft, that the following new > > >>line exists within the description of pwdExpireWarning: >>If not 0, the value must be smaller than the value of the pwdMaxAge >>attribute. >> >>This seriously implies that the author's intention is to ensure that >>the >>warning time does not exceed the maximum age of the password. >> >>I'm not extremely passionate about whether a user should receive > > their > >>full warning period. Some consensus on this issue, and the author's >>opinion (Jim?) would be good though. >> >> >>Andrew Sciberras >>eB2Bcom - Software Engineer >> >> >> >> >> > > ------------------------------------------------------------------------ > >>_______________________________________________ >>Ldapext mailing list >> Ldapext@ietf.org >> https://www1.ietf.org/mailman/listinfo/ldapext > > > > --=__Part1C3C2DD5.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This does bring up another point I wanted to discuss though...
 
This draft was written way back when it was popular to assign OIDs in = I-D's. A practice that has lost favor partly due to implementations using = those OIDs and experiencing problems as semantics changed but OIDs = didn't.
 
I'd like to move this I-D forward, and I don't want to be tied to any = semantics defined in previous versions. I propose that we replace the = existing OIDs with requests for IANA OIDs. This way, existing implementatio= ns won't appear to be invalid according to the current and future = revisions, and I won't have to worry so much about breaking existing = implementations.
 
What do other's think?
 
Jim

>>> Andrew Sciberras <andrew.sciberras@eB2Bcom.= com> 10/25/04 6:08:05 PM >>>
Sorry Jim... I see where your = coming from now :)

Yep I agree.

Andrew.

Jim Sermershei= m wrote:

> Actually, I suggested that the password expire at its = max age (regardles
> of whether any warnings have been sent).
>=
> Jim
>
>
>>>>Andrew Sciberras = < andrew.sciberras@eB= 2Bcom.com > 10/25/04 3:36:19 PM
>>>>
> =
> G'Day
>
> I'm generally satisfied with this.
> =
> If any directories exist today that use the following model:
&g= t; * pwdMaxAge - Absolute maximum age of the password
> * pwdExpireWa= rning - Time period before the max age in which warnings
> will be = delivered,
>
> Then changing the semantics of these attributes= would lead to
> unexpected
> behavior if an organization = upgraded their directory server to the new
>
> functionality.<= BR>>
> Eg. A directory that wants to warn people 6 months before = their
> password
> is due to expire.
> pwdMaxAge =3D = 31536000 (1 year)
> pwdExpireWarning =3D 15768000 (6 Months)
> =
> Updating the directory server to one that supports Jim's = suggestion
> below will result in the password reaching its max = age, then remaining
>
> valid for another 6 months.
> =
>
> I'm not too sure if this is likely to be a serious = problem for
> implementations, but some text in the security = considerations of the
> draft indicating this might be appropriate.<= BR>>
> Cheers
> _________________________________________> Andrew Sciberras
> eB2Bcom - Software Engineer
> =
>
> Jim Sermersheim wrote:
>
>
>>I = believe the intent (however wrongly formulated) was to allow the
> =
> user
>
>>to receive a warning no matter what. = Even if the password's max age
>
> has
>
>>pas= sed, the user would be allowed pwdExpireWarning seconds to change
> =
> the
>
>>pwd. The definition of pwdExpireWarning = talks about this in a not
>
> very
>
>>precise= way (The number of seconds before the password will expire
> =
> after
>
>>the user is first warned of its = upcoming expiration.)
>>
>>Some history to help make = sense of things:
>>
>>The password policy I-D was = created as a blend of the (then)
>
> Netscape
> =
>>and Novell directory password policies.
>>
>>= I believe the original implementors of pwdExpireWarning (Netscape)
> =
> used
>
>>this to both warn of expiration, and = also allow some kind of grace
>
> login
>
>>pe= riod.
>>Novell's implementation didn't include the notion of a = warning
>
> period.
>
>>Only a number of = grace logins.
>>
>>So now we have two ways of achieving = 'grace login'.
>>
>>A better way of specifying the = pwdExpireWarning and pwdMaxAge
>
> concepts
>
>&g= t;would have been to use one attribute to specify an age at which = an
>>expiration warning is sent, and another attribute specified = how long
>>these warnings will continue before the password = finally expires.
>>
>>I dislike having two similar but = different grace mechanisms, so I
>>propose that we remove = pwdExpireWarned, and expire the password when
>
> it
> =
>>reaches pwdMaxAge (regardless of whether any warnings have = been
>
> sent).
>
>>I'll update the I-D to = reflect this without debate (because the
>>deadline is so near), = and we can go from there.
>>
>>Jim
>>
>>= ;
>>
>>>>>Andrew Sciberras < andrew.sciberras@eB2Bcom.com = > 9/14/04 7:48:25
>
> PM
>
>>Hi Niel,
&g= t;>
>>
>>Neil Dunbar wrote:
>><SNIP>>>
>>>The pwdMaxAge should be the absolute maximum time = that the password
>>
>>can
>>
>>
>= ;>>be used by anyone as a credential. The pwdExpirationWarning time, = I
>>>think, should be the earliest opportunity that the = directory server
>>
>>can
>>
>>
>= >>warn the user that his/her password is approaching expiry. If = the
>>
>>user
>>
>>
>>>come= s into the expiry period late in the game - tough. You can
>>
&= gt;>always
>>
>>
>>>use the grace logins = feature to allow the user with the dud password
>>
>>to>>
>>
>>>change it after it has ceased to be = a meaningful credential for
>>
>>general
>>
&= gt;>
>>>directory operations
>>
>></SN= IP>
>>
>>
>>If someone was to implement the = draft in its current form, their
>
> first
>
>>= ;warning time would indicate the time difference between the current
>= ;>time
>>and the time that the password is due to expire. = Subsequent logins
>>would
>>result in a warning time = that will go beyond the specified pwdMaxAge
>
>
>>al= lowing the user to receive their full warning period.
>>
>&g= t;Our implementation, which was based around the -05 version of the
>=
> draft
>
>>handled this inconsistency by = returning an initial warning message of
>
>
>>pwdExp= ireWarning.
>>
>>I've now noticed, in version -07 of the = draft, that the following new
>
>
>>line exists = within the description of pwdExpireWarning:
>>If not 0, the value = must be smaller than the value of the pwdMaxAge
>>attribute.
&= gt;>
>>This seriously implies that the author's intention is = to ensure that
>>the
>>warning time does not exceed the = maximum age of the password.
>>
>>I'm not extremely = passionate about whether a user should receive
>
> their
&g= t;
>>full warning period. Some consensus on this issue, and the = author's
>>opinion (Jim?) would be good though.
>>
&g= t;>
>>Andrew Sciberras
>>eB2Bcom - Software Engineer>>
>>
>>
>>
>>
> =
> ------------------------------------------------------------------= ------
>
>>_______________________________________________<= BR>>>Ldapext mailing list
>> Ldapext@ietf.org
>> https://www1.ietf.org/mailman/listinfo/lda= pext
>
>
>
>

--=__Part1C3C2DD5.0__=-- --===============1617627559== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============1617627559==-- From ldapext-bounces@ietf.org Mon Oct 25 20:54:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21945 for ; Mon, 25 Oct 2004 20:07:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEXT-0005OH-W2; Mon, 25 Oct 2004 19:46:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMDqH-0001Ay-U2 for ldapext@megatron.ietf.org; Mon, 25 Oct 2004 19:01:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08842 for ; Mon, 25 Oct 2004 19:01:30 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CME3o-00018N-VT for ldapext@ietf.org; Mon, 25 Oct 2004 19:15:33 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 25 Oct 2004 17:01:02 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Mon, 25 Oct 2004 17:00:35 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Re: Password Policy for LDAP Directories Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb Cc: ldapext@ietf.org, gabriele.garuglieri@infoblu.it X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1124474842==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============1124474842== Content-Type: multipart/alternative; boundary="=__Part52726383.2__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part52726383.2__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Actually, I suggested that the password expire at its max age (regardles of whether any warnings have been sent). Jim >>> Andrew Sciberras 10/25/04 3:36:19 PM >>> G'Day I'm generally satisfied with this. If any directories exist today that use the following model: * pwdMaxAge - Absolute maximum age of the password * pwdExpireWarning - Time period before the max age in which warnings will be delivered, Then changing the semantics of these attributes would lead to unexpected behavior if an organization upgraded their directory server to the new functionality. Eg. A directory that wants to warn people 6 months before their password is due to expire. pwdMaxAge = 31536000 (1 year) pwdExpireWarning = 15768000 (6 Months) Updating the directory server to one that supports Jim's suggestion below will result in the password reaching its max age, then remaining valid for another 6 months. I'm not too sure if this is likely to be a serious problem for implementations, but some text in the security considerations of the draft indicating this might be appropriate. Cheers _________________________________________ Andrew Sciberras eB2Bcom - Software Engineer Jim Sermersheim wrote: > I believe the intent (however wrongly formulated) was to allow the user > to receive a warning no matter what. Even if the password's max age has > passed, the user would be allowed pwdExpireWarning seconds to change the > pwd. The definition of pwdExpireWarning talks about this in a not very > precise way (The number of seconds before the password will expire after > the user is first warned of its upcoming expiration.) > > Some history to help make sense of things: > > The password policy I-D was created as a blend of the (then) Netscape > and Novell directory password policies. > > I believe the original implementors of pwdExpireWarning (Netscape) used > this to both warn of expiration, and also allow some kind of grace login > period. > Novell's implementation didn't include the notion of a warning period. > Only a number of grace logins. > > So now we have two ways of achieving 'grace login'. > > A better way of specifying the pwdExpireWarning and pwdMaxAge concepts > would have been to use one attribute to specify an age at which an > expiration warning is sent, and another attribute specified how long > these warnings will continue before the password finally expires. > > I dislike having two similar but different grace mechanisms, so I > propose that we remove pwdExpireWarned, and expire the password when it > reaches pwdMaxAge (regardless of whether any warnings have been sent). > > I'll update the I-D to reflect this without debate (because the > deadline is so near), and we can go from there. > > Jim > > >>>>Andrew Sciberras < andrew.sciberras@eB2Bcom.com > 9/14/04 7:48:25 PM >>>> > > Hi Niel, > > > Neil Dunbar wrote: > > >>The pwdMaxAge should be the absolute maximum time that the password > > can > >>be used by anyone as a credential. The pwdExpirationWarning time, I >>think, should be the earliest opportunity that the directory server > > can > >>warn the user that his/her password is approaching expiry. If the > > user > >>comes into the expiry period late in the game - tough. You can > > always > >>use the grace logins feature to allow the user with the dud password > > to > >>change it after it has ceased to be a meaningful credential for > > general > >>directory operations > > > > > If someone was to implement the draft in its current form, their first > > warning time would indicate the time difference between the current > time > and the time that the password is due to expire. Subsequent logins > would > result in a warning time that will go beyond the specified pwdMaxAge > allowing the user to receive their full warning period. > > Our implementation, which was based around the -05 version of the draft > > handled this inconsistency by returning an initial warning message of > pwdExpireWarning. > > I've now noticed, in version -07 of the draft, that the following new > line exists within the description of pwdExpireWarning: > If not 0, the value must be smaller than the value of the pwdMaxAge > attribute. > > This seriously implies that the author's intention is to ensure that > the > warning time does not exceed the maximum age of the password. > > I'm not extremely passionate about whether a user should receive their > > full warning period. Some consensus on this issue, and the author's > opinion (Jim?) would be good though. > > > Andrew Sciberras > eB2Bcom - Software Engineer > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext --=__Part52726383.2__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Actually, I suggested that the password expire at its max age = (regardles of whether any warnings have been sent).
 
Jim

>>> Andrew Sciberras <andrew.sciberras@eB2Bcom.= com> 10/25/04 3:36:19 PM >>>
G'Day

I'm generally = satisfied with this.

If any directories exist today that use the = following model:
* pwdMaxAge - Absolute maximum age of the password
*= pwdExpireWarning - Time period before the max age in which warnings =
will be delivered,

Then changing the semantics of these = attributes would lead to unexpected
behavior if an organization = upgraded their directory server to the new
functionality.

Eg. A = directory that wants to warn people 6 months before their password
is = due to expire.
pwdMaxAge =3D 31536000 (1 year)
pwdExpireWarning =3D = 15768000 (6 Months)

Updating the directory server to one that = supports Jim's suggestion
below will result in the password reaching = its max age, then remaining
valid for another 6 months.


I'm = not too sure if this is likely to be a serious problem for
implementati= ons, but some text in the security considerations of the
draft = indicating this might be appropriate.

Cheers
____________________= _____________________
Andrew Sciberras
eB2Bcom - Software Engineer

Jim Sermersheim wrote:

> I believe the intent (however = wrongly formulated) was to allow the user
> to receive a warning no = matter what. Even if the password's max age has
> passed, the user = would be allowed pwdExpireWarning seconds to change the
> pwd. The = definition of pwdExpireWarning talks about this in a not very
> = precise way (The number of seconds before the password will expire = after
> the user is first warned of its upcoming expiration.)
>=
> Some history to help make sense of things:
>
> The = password policy I-D was created as a blend of the (then) Netscape
> = and Novell directory password policies.
>
> I believe the = original implementors of pwdExpireWarning (Netscape) used
> this to = both warn of expiration, and also allow some kind of grace login
> = period.
> Novell's implementation didn't include the notion of a = warning period.
> Only a number of grace logins.
>
> So = now we have two ways of achieving 'grace login'.
>
> A better = way of specifying the pwdExpireWarning and pwdMaxAge concepts
> = would have been to use one attribute to specify an age at which an
> = expiration warning is sent, and another attribute specified how long
>= ; these warnings will continue before the password finally expires.
>=
> I dislike having two similar but different grace mechanisms, so = I
> propose that we remove pwdExpireWarned, and expire the password = when it
> reaches pwdMaxAge (regardless of whether any warnings have = been sent).
>
> I'll update the I-D to reflect this without = debate (because the
> deadline is so near), and we can go from = there.
>
> Jim
>
>
>>>>Andrew = Sciberras < andrew.sc= iberras@eB2Bcom.com > 9/14/04 7:48:25 PM
>>>>
= >
> Hi Niel,
>
>
> Neil Dunbar wrote:
>= <SNIP>
>
>>The pwdMaxAge should be the absolute = maximum time that the password
>
> can
>
>>be = used by anyone as a credential. The pwdExpirationWarning time, I
>>= ;think, should be the earliest opportunity that the directory server
>= ;
> can
>
>>warn the user that his/her password is = approaching expiry. If the
>
> user
>
>>comes = into the expiry period late in the game - tough. You can
>
> = always
>
>>use the grace logins feature to allow the user = with the dud password
>
> to
>
>>change it = after it has ceased to be a meaningful credential for
>
> = general
>
>>directory operations
>
> = </SNIP>
>
>
> If someone was to implement the = draft in its current form, their first
>
> warning time would = indicate the time difference between the current
> time
> and = the time that the password is due to expire. Subsequent logins
> = would
> result in a warning time that will go beyond the specified = pwdMaxAge
> allowing the user to receive their full warning = period.
>
> Our implementation, which was based around the = -05 version of the draft
>
> handled this inconsistency by = returning an initial warning message of
> pwdExpireWarning.
> =
> I've now noticed, in version -07 of the draft, that the following = new
> line exists within the description of pwdExpireWarning:
>= ; If not 0, the value must be smaller than the value of the pwdMaxAge =
> attribute.
>
> This seriously implies that the = author's intention is to ensure that
> the
> warning time = does not exceed the maximum age of the password.
>
> I'm not = extremely passionate about whether a user should receive their
> =
> full warning period. Some consensus on this issue, and the = author's
> opinion (Jim?) would be good though.
>
> =
> Andrew Sciberras
> eB2Bcom - Software Engineer
> =
>
>
>
> ---------------------------------------= ---------------------------------
>
> ________________________= _______________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www1.ietf.o= rg/mailman/listinfo/ldapext

--=__Part52726383.2__=-- --===============1124474842== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============1124474842==-- From ldapext-bounces@ietf.org Mon Oct 25 22:16:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01426 for ; Mon, 25 Oct 2004 22:16:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMGpM-0002eA-SE; Mon, 25 Oct 2004 22:12:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMGom-0002Rf-Et for ldapext@megatron.ietf.org; Mon, 25 Oct 2004 22:12:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01029 for ; Mon, 25 Oct 2004 22:12:09 -0400 (EDT) Received: from amos.eb2b.com.au ([210.8.191.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMH2K-0007Oe-3v for ldapext@ietf.org; Mon, 25 Oct 2004 22:26:13 -0400 Received: from [192.168.1.155] (210.8.191.250) by amos.eb2b.com.au (7.1.016.1) (authenticated as andrew.sciberras) id 416CAD380000157A; Tue, 26 Oct 2004 12:21:00 +1000 Message-ID: <417DB235.8080508@eB2Bcom.com> Date: Tue, 26 Oct 2004 12:11:01 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-au, en-gb, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Password Policy OIDs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew.sciberras@eB2Bcom.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit G'Day Jim, I think that this is a good idea, however your email suggests that changing the OID's will disambiguate the semantics by which a password policy is being enforced. Do you plan to change the short name descriptors of the attributes as well? Andrew Sciberras Jim Sermersheim wrote: > This does bring up another point I wanted to discuss though... > > This draft was written way back when it was popular to assign OIDs in > I-D's. A practice that has lost favor partly due to implementations > using those OIDs and experiencing problems as semantics changed but OIDs > didn't. > > I'd like to move this I-D forward, and I don't want to be tied to any > semantics defined in previous versions. I propose that we replace the > existing OIDs with requests for IANA OIDs. This way, existing > implementations won't appear to be invalid according to the current and > future revisions, and I won't have to worry so much about breaking > existing implementations. > > What do other's think? > > Jim > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Oct 25 23:52:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08005 for ; Mon, 25 Oct 2004 23:52:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMIMN-0003Iz-RK; Mon, 25 Oct 2004 23:50:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMILc-00035m-Tm for ldapext@megatron.ietf.org; Mon, 25 Oct 2004 23:50:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07621 for ; Mon, 25 Oct 2004 23:50:09 -0400 (EDT) Received: from mail17.ca.com ([155.35.248.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMIZ8-0000hg-NX for ldapext@ietf.org; Tue, 26 Oct 2004 00:04:15 -0400 Received: from ausyms21.ca.com ([155.35.201.5]) by mail17.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 26 Oct 2004 13:49:34 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ldapext] Password Policy OIDs Date: Tue, 26 Oct 2004 13:49:33 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B638101EF3A1E@ausyms21.ca.com> Thread-Topic: [ldapext] Password Policy OIDs Thread-Index: AcS69Yp4c5tqo68uR5yheDW7cT5r5AAGPbEw From: "Ramsay, Ron" To: "Jim Sermersheim" , X-OriginalArrivalTime: 26 Oct 2004 03:49:34.0080 (UTC) FILETIME=[CE731000:01C4BB0E] X-Spam-Score: 0.0 (/) X-Scan-Signature: c07eeb7900970a16fe4056cc74ae9ce2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0842862642==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a multi-part message in MIME format. --===============0842862642== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BB0E.CE49F315" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4BB0E.CE49F315 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It appears not to have that effect. Unless you change the names as well, = you can have an old client appearing to communicate with a new server, = or a new client appearing to communicate with an old server, and yet = they can misunderstand each other. =20 Ron -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On = Behalf Of Jim Sermersheim Sent: Tuesday, 26 October 2004 10:44 To: ldapext@ietf.org Subject: [ldapext] Password Policy OIDs This does bring up another point I wanted to discuss though... =20 This draft was written way back when it was popular to assign OIDs in = I-D's. A practice that has lost favor partly due to implementations = using those OIDs and experiencing problems as semantics changed but OIDs = didn't. =20 I'd like to move this I-D forward, and I don't want to be tied to any = semantics defined in previous versions. I propose that we replace the = existing OIDs with requests for IANA OIDs. This way, existing = implementations won't appear to be invalid according to the current and = future revisions, and I won't have to worry so much about breaking = existing implementations. =20 What do other's think? =20 Jim >>> Andrew Sciberras 10/25/04 6:08:05 PM = >>> Sorry Jim... I see where your coming from now :) Yep I agree. Andrew. Jim Sermersheim wrote: > Actually, I suggested that the password expire at its max age = (regardles > of whether any warnings have been sent). >=20 > Jim >=20 >=20 >>>>Andrew Sciberras < andrew.sciberras@eB2Bcom.com > 10/25/04 3:36:19 = PM >>>> >=20 > G'Day >=20 > I'm generally satisfied with this. >=20 > If any directories exist today that use the following model: > * pwdMaxAge - Absolute maximum age of the password > * pwdExpireWarning - Time period before the max age in which warnings=20 > will be delivered, >=20 > Then changing the semantics of these attributes would lead to > unexpected=20 > behavior if an organization upgraded their directory server to the new >=20 > functionality. >=20 > Eg. A directory that wants to warn people 6 months before their > password=20 > is due to expire. > pwdMaxAge =3D 31536000 (1 year) > pwdExpireWarning =3D 15768000 (6 Months) >=20 > Updating the directory server to one that supports Jim's suggestion=20 > below will result in the password reaching its max age, then remaining >=20 > valid for another 6 months. >=20 >=20 > I'm not too sure if this is likely to be a serious problem for=20 > implementations, but some text in the security considerations of the=20 > draft indicating this might be appropriate. >=20 > Cheers > _________________________________________ > Andrew Sciberras > eB2Bcom - Software Engineer >=20 >=20 > Jim Sermersheim wrote: >=20 >=20 >>I believe the intent (however wrongly formulated) was to allow the >=20 > user >=20 >>to receive a warning no matter what. Even if the password's max age >=20 > has >=20 >>passed, the user would be allowed pwdExpireWarning seconds to change >=20 > the >=20 >>pwd. The definition of pwdExpireWarning talks about this in a not >=20 > very >=20 >>precise way (The number of seconds before the password will expire >=20 > after >=20 >>the user is first warned of its upcoming expiration.) >> >>Some history to help make sense of things: >> >>The password policy I-D was created as a blend of the (then) >=20 > Netscape >=20 >>and Novell directory password policies. >> >>I believe the original implementors of pwdExpireWarning (Netscape) >=20 > used >=20 >>this to both warn of expiration, and also allow some kind of grace >=20 > login >=20 >>period. >>Novell's implementation didn't include the notion of a warning >=20 > period. >=20 >>Only a number of grace logins. >> >>So now we have two ways of achieving 'grace login'. >> >>A better way of specifying the pwdExpireWarning and pwdMaxAge >=20 > concepts >=20 >>would have been to use one attribute to specify an age at which an >>expiration warning is sent, and another attribute specified how long >>these warnings will continue before the password finally expires. >> >>I dislike having two similar but different grace mechanisms, so I >>propose that we remove pwdExpireWarned, and expire the password when >=20 > it >=20 >>reaches pwdMaxAge (regardless of whether any warnings have been >=20 > sent). >=20 >>I'll update the I-D to reflect this without debate (because the >>deadline is so near), and we can go from there. >> >>Jim >> >> >> >>>>>Andrew Sciberras < andrew.sciberras@eB2Bcom.com > 9/14/04 7:48:25 >=20 > PM >=20 >>Hi Niel, >> >> >>Neil Dunbar wrote: >> >> >>>The pwdMaxAge should be the absolute maximum time that the password >> >>can >> >> >>>be used by anyone as a credential. The pwdExpirationWarning time, I >>>think, should be the earliest opportunity that the directory server >> >>can >> >> >>>warn the user that his/her password is approaching expiry. If the >> >>user >> >> >>>comes into the expiry period late in the game - tough. You can >> >>always >> >> >>>use the grace logins feature to allow the user with the dud password >> >>to >> >> >>>change it after it has ceased to be a meaningful credential for >> >>general >> >> >>>directory operations=20 >> >> >> >> >>If someone was to implement the draft in its current form, their >=20 > first >=20 >>warning time would indicate the time difference between the current >>time=20 >>and the time that the password is due to expire. Subsequent logins >>would=20 >>result in a warning time that will go beyond the specified pwdMaxAge >=20 >=20 >>allowing the user to receive their full warning period. >> >>Our implementation, which was based around the -05 version of the >=20 > draft >=20 >>handled this inconsistency by returning an initial warning message of >=20 >=20 >>pwdExpireWarning. >> >>I've now noticed, in version -07 of the draft, that the following new >=20 >=20 >>line exists within the description of pwdExpireWarning: >>If not 0, the value must be smaller than the value of the pwdMaxAge=20 >>attribute. >> >>This seriously implies that the author's intention is to ensure that >>the=20 >>warning time does not exceed the maximum age of the password. >> >>I'm not extremely passionate about whether a user should receive >=20 > their >=20 >>full warning period. Some consensus on this issue, and the author's=20 >>opinion (Jim?) would be good though. >> >> >>Andrew Sciberras >>eB2Bcom - Software Engineer >> >> >> >> >> >=20 > = ------------------------------------------------------------------------ >=20 >>_______________________________________________ >>Ldapext mailing list >> Ldapext@ietf.org=20 >> https://www1.ietf.org/mailman/listinfo/ldapext=20 >=20 >=20 >=20 >=20 ------_=_NextPart_001_01C4BB0E.CE49F315 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It appears not to have that = effect. Unless=20 you change the names as well, you can have an old client appearing to=20 communicate with a new server, or a new client appearing to = communicate=20 with an old server, and yet they can misunderstand each = other.
 
Ron
-----Original = Message-----
From: ldapext-bounces@ietf.org=20 [mailto:ldapext-bounces@ietf.org]On Behalf Of Jim=20 Sermersheim
Sent: Tuesday, 26 October 2004 = 10:44
To:=20 ldapext@ietf.org
Subject: [ldapext] Password Policy=20 OIDs

This does bring up another point I wanted to discuss = though...
 
This draft was written way back when it was popular to assign = OIDs in=20 I-D's. A practice that has lost favor partly due to implementations = using=20 those OIDs and experiencing problems as semantics changed but OIDs=20 didn't.
 
I'd like to move this I-D forward, and I don't want to be tied to = any=20 semantics defined in previous versions. I propose that we replace the = existing=20 OIDs with requests for IANA OIDs. This way, existing implementations = won't=20 appear to be invalid according to the current and future revisions, = and I=20 won't have to worry so much about breaking existing = implementations.
 
What do other's think?
 
Jim

>>> Andrew Sciberras=20 <andrew.sciberras@eB2Bcom.com> 10/25/04 6:08:05 PM = >>>
Sorry=20 Jim... I see where your coming from now :)

Yep I=20 agree.

Andrew.

Jim Sermersheim wrote:

> = Actually, I=20 suggested that the password expire at its max age (regardles
> = of=20 whether any warnings have been sent).
>
> Jim
> =
>=20
>>>>Andrew Sciberras < andrew.sciberras@eB2Bcom.com= =20 > 10/25/04 3:36:19 PM
>>>>
>
> = G'Day
>=20
> I'm generally satisfied with this.
>
> If any=20 directories exist today that use the following model:
> * = pwdMaxAge -=20 Absolute maximum age of the password
> * pwdExpireWarning - Time = period=20 before the max age in which warnings
> will be = delivered,
>=20
> Then changing the semantics of these attributes would lead = to
>=20 unexpected
> behavior if an organization upgraded their = directory=20 server to the new
>
> functionality.
>
> Eg. = A=20 directory that wants to warn people 6 months before their
> = password=20
> is due to expire.
> pwdMaxAge =3D 31536000 (1 = year)
>=20 pwdExpireWarning =3D 15768000 (6 Months)
>
> Updating the = directory=20 server to one that supports Jim's suggestion
> below will = result in the=20 password reaching its max age, then remaining
>
> valid = for=20 another 6 months.
>
>
> I'm not too sure if this = is likely=20 to be a serious problem for
> implementations, but some text in = the=20 security considerations of the
> draft indicating this might be = appropriate.
>
> Cheers
>=20 _________________________________________
> Andrew = Sciberras
>=20 eB2Bcom - Software Engineer
>
>
> Jim Sermersheim=20 wrote:
>
>
>>I believe the intent (however = wrongly=20 formulated) was to allow the
>
> user
> =
>>to=20 receive a warning no matter what. Even if the password's max = age
>=20
> has
>
>>passed, the user would be allowed=20 pwdExpireWarning seconds to change
>
> the
>=20
>>pwd. The definition of pwdExpireWarning talks about this = in a=20 not
>
> very
>
>>precise way (The number = of=20 seconds before the password will expire
>
> after
> =
>>the user is first warned of its upcoming=20 expiration.)
>>
>>Some history to help make sense of = things:
>>
>>The password policy I-D was created as = a blend=20 of the (then)
>
> Netscape
>
>>and Novell = directory password policies.
>>
>>I believe the = original=20 implementors of pwdExpireWarning (Netscape)
>
> = used
>=20
>>this to both warn of expiration, and also allow some kind = of=20 grace
>
> login
> =
>>period.
>>Novell's=20 implementation didn't include the notion of a warning
>
> = period.
>
>>Only a number of grace=20 logins.
>>
>>So now we have two ways of achieving = 'grace=20 login'.
>>
>>A better way of specifying the = pwdExpireWarning=20 and pwdMaxAge
>
> concepts
>
>>would have = been to=20 use one attribute to specify an age at which an
>>expiration = warning=20 is sent, and another attribute specified how long
>>these = warnings=20 will continue before the password finally = expires.
>>
>>I=20 dislike having two similar but different grace mechanisms, so=20 I
>>propose that we remove pwdExpireWarned, and expire the = password=20 when
>
> it
>
>>reaches pwdMaxAge = (regardless of=20 whether any warnings have been
>
> sent).
>=20
>>I'll update the I-D to reflect this without debate = (because=20 the
>>deadline is so near), and we can go from=20 = there.
>>
>>Jim
>>
>>
>>
= >>>>>Andrew=20 Sciberras < andrew.sciberras@eB2Bcom.com= =20 > 9/14/04 7:48:25
>
> PM
>
>>Hi=20 Niel,
>>
>>
>>Neil Dunbar=20 wrote:
>><SNIP>
>>
>>>The = pwdMaxAge should=20 be the absolute maximum time that the=20 = password
>>
>>can
>>
>>
>>&g= t;be=20 used by anyone as a credential. The pwdExpirationWarning time,=20 I
>>>think, should be the earliest opportunity that the = directory=20 = server
>>
>>can
>>
>>
>>>= warn=20 the user that his/her password is approaching expiry. If=20 = the
>>
>>user
>>
>>
>>>co= mes=20 into the expiry period late in the game - tough. You=20 = can
>>
>>always
>>
>>
>>>= use=20 the grace logins feature to allow the user with the dud=20 = password
>>
>>to
>>
>>
>>>= ;change=20 it after it has ceased to be a meaningful credential=20 = for
>>
>>general
>>
>>
>>>= ;directory=20 operations=20 =
>>
>></SNIP>
>>
>>
>>= If=20 someone was to implement the draft in its current form, their
> =
>=20 first
>
>>warning time would indicate the time = difference=20 between the current
>>time
>>and the time that the = password=20 is due to expire. Subsequent logins
>>would =
>>result in a=20 warning time that will go beyond the specified pwdMaxAge
> =
>=20
>>allowing the user to receive their full warning=20 period.
>>
>>Our implementation, which was based = around the=20 -05 version of the
>
> draft
>
>>handled = this=20 inconsistency by returning an initial warning message of
> =
>=20
>>pwdExpireWarning.
>>
>>I've now noticed, = in=20 version -07 of the draft, that the following new
>
>=20
>>line exists within the description of=20 pwdExpireWarning:
>>If not 0, the value must be smaller than = the=20 value of the pwdMaxAge =
>>attribute.
>>
>>This=20 seriously implies that the author's intention is to ensure = that
>>the=20
>>warning time does not exceed the maximum age of the=20 password.
>>
>>I'm not extremely passionate about = whether a=20 user should receive
>
> their
>
>>full = warning=20 period. Some consensus on this issue, and the author's =
>>opinion=20 (Jim?) would be good though.
>>
>>
>>Andrew = Sciberras
>>eB2Bcom - Software=20 = Engineer
>>
>>
>>
>>
>>
&= gt;=20
>=20 = ------------------------------------------------------------------------<= BR>>=20 =
>>_______________________________________________
>>Ld= apext=20 mailing list
>> Ldapext@ietf.org =
>> https://www1.ietf= .org/mailman/listinfo/ldapext=20
>
>
>
> =

------_=_NextPart_001_01C4BB0E.CE49F315-- --===============0842862642== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0842862642==-- From ldapext-bounces@ietf.org Tue Oct 26 01:19:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13481 for ; Tue, 26 Oct 2004 01:19:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMJii-0005Ib-CW; Tue, 26 Oct 2004 01:18:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMJhY-000584-BD for ldapext@megatron.ietf.org; Tue, 26 Oct 2004 01:16:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13361 for ; Tue, 26 Oct 2004 01:16:53 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMJv7-0002Mg-Dj for ldapext@ietf.org; Tue, 26 Oct 2004 01:30:58 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 25 Oct 2004 23:16:23 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Mon, 25 Oct 2004 23:16:09 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Password Policy OIDs Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0194030767==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0194030767== Content-Type: multipart/alternative; boundary="=__Part00203189.1__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part00203189.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Yeah, I suppose we could do that as well. I'm looking at the differences between the 00 version and the 09 version: For the pwdPolicy class: - pwdDefaultStorageScheme has been dropped - pwdFailureCountResetTime has changed to pwdFailureCountInterval - pwdGraceLoginLimit has changed to pwdGraceAuthNLimit - pwdCheckSyntax has changed to pwdCheckQuality. It's syntax changed from boolean to integer, but I'm proposing to chainge it to oid - pwdAttribute has been added as a MUST - The usage of all attributes on pwdPolicy has changed from directoryOperation to userOperation - The OID assigned to all attribute has changed at least once There used to be a pwdInfoObj aux class which defined the state attribute. That's gone, but the attributes have gone through these changes: - pwdExpirationTime and pwdAllowChangeTime have been replaced by pwdChangedTime - pwdExpWarned has been dropped - pwdRetryCount and pwdRetryCountResetTime have been replaced by pwdFailureTime - pwdAccountUnlockTime has been replaced by pwdAccountLockedTime - pwdGraceLeft has been replaced by pwdGraceUseTime - The data format of pwdHistory has changed - pwdReset has been added - pwdPolicySubEntry has been added - The OIDs of these have all changed at least once as well Version 04 (July 2001) introduced the OIDs (prior to that, they actually used OIDs relative to an unnamed arc. Less has changed between the 04 and 08 versions in the schema definitions, but semantic changed (including buggy specifications) have changed over those four versions. I also believe most implementations were written to one of 04 - 07 So, it seems a good time to me to update the OIDs, as well as the names. I prefer to keep names that I don't believe will change syntactically or semantically. These include: pwdMinAge, pwdMaxAge, and pwdInHistory (though I might like pwdHistorySize better), pwdHistory (though I can see the format possibly changing, thus a name change would be good), and pwdPolicySubentry. I can think of similar or better names for the rest of them. Jim >>> Andrew Sciberras 10/25/04 8:11:01 PM >>> G'Day Jim, I think that this is a good idea, however your email suggests that changing the OID's will disambiguate the semantics by which a password policy is being enforced. Do you plan to change the short name descriptors of the attributes as well? Andrew Sciberras Jim Sermersheim wrote: > This does bring up another point I wanted to discuss though... > > This draft was written way back when it was popular to assign OIDs in > I-D's. A practice that has lost favor partly due to implementations > using those OIDs and experiencing problems as semantics changed but OIDs > didn't. > > I'd like to move this I-D forward, and I don't want to be tied to any > semantics defined in previous versions. I propose that we replace the > existing OIDs with requests for IANA OIDs. This way, existing > implementations won't appear to be invalid according to the current and > future revisions, and I won't have to worry so much about breaking > existing implementations. > > What do other's think? > > Jim > --=__Part00203189.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yeah, I suppose we could do that as well. I'm looking at the = differences between the 00 version and the 09 version:
 
For the pwdPolicy class:
- pwdDefaultStorageScheme has been dropped
- pwdFailureCountResetTime has changed to pwdFailureCountInterval =
- pwdGraceLoginLimit has changed to pwdGraceAuthNLimit
- pwdCheckSyntax has changed to pwdCheckQuality. It's syntax changed = from boolean to integer, but I'm proposing to chainge it to oid
- pwdAttribute has been added as a MUST
- The usage of all attributes on pwdPolicy has changed from directoryO= peration to userOperation
- The OID assigned to all attribute has changed at least once
 
There used to be a pwdInfoObj aux class which defined the state = attribute. That's gone, but the attributes have gone through these = changes:
- pwdExpirationTime and pwdAllowChangeTime have been replaced by = pwdChangedTime
- pwdExpWarned has been dropped
- pwdRetryCount and pwdRetryCountResetTime have been replaced by = pwdFailureTime
- pwdAccountUnlockTime has been replaced by pwdAccountLockedTime
=
- pwdGraceLeft has been replaced by pwdGraceUseTime
- The data format of pwdHistory has changed
- pwdReset has been added
- pwdPolicySubEntry has been added
- The OIDs of these have all changed at least once as well
 
Version 04 (July 2001) introduced the OIDs (prior to that, they = actually used OIDs relative to an unnamed arc. Less has changed between = the 04 and 08 versions in the schema definitions, but semantic changed = (including buggy specifications) have changed over those four versions. I = also believe most implementations were written to one of 04 - 07
 
So, it seems a good time to me to update the OIDs, as well as the = names. I prefer to keep names that I don't believe will change syntacticall= y or semantically. These include:
pwdMinAge, pwdMaxAge, and pwdInHistory (though I might like pwdHistory= Size better), pwdHistory (though I can see the format possibly changing, = thus a name change would be good), and pwdPolicySubentry. I can think of = similar or better names for the rest of them.
Jim

>>> Andrew Sciberras <andrew.sciberras@eB2Bcom.com>= 10/25/04 8:11:01 PM >>>
G'Day Jim,

I think that this = is a good idea, however your email suggests that
changing the OID's = will disambiguate the semantics by which a password
policy is being = enforced. Do you plan to change the short name
descriptors of the = attributes as well?


Andrew Sciberras


Jim Sermersheim = wrote:

> This does bring up another point I wanted to discuss = though...
>
> This draft was written way back when it was = popular to assign OIDs in
> I-D's. A practice that has lost favor = partly due to implementations
> using those OIDs and experiencing = problems as semantics changed but OIDs
> didn't.
>
> = I'd like to move this I-D forward, and I don't want to be tied to = any
> semantics defined in previous versions. I propose that we = replace the
> existing OIDs with requests for IANA OIDs. This way, = existing
> implementations won't appear to be invalid according to = the current and
> future revisions, and I won't have to worry so = much about breaking
> existing implementations.
>
> = What do other's think?
>
> Jim
>
--=__Part00203189.1__=-- --===============0194030767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0194030767==-- From ldapext-bounces@ietf.org Tue Oct 26 04:42:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11485 for ; Tue, 26 Oct 2004 04:42:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMMoD-0001v9-5n; Tue, 26 Oct 2004 04:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMMjC-0000sg-4O for ldapext@megatron.ietf.org; Tue, 26 Oct 2004 04:30:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10310 for ; Tue, 26 Oct 2004 04:30:47 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMMwo-0005ee-E3 for ldapext@ietf.org; Tue, 26 Oct 2004 04:44:54 -0400 Received: from odin.France.Sun.COM ([129.157.174.8]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9Q8Uh7q008308; Tue, 26 Oct 2004 01:30:44 -0700 (PDT) Received: from [129.157.211.132] (dhcp-gnb07-211-132 [129.157.211.132]) by odin.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9Q8UgLi000407; Tue, 26 Oct 2004 10:30:42 +0200 (MEST) Message-ID: <417E0B1A.3090806@Sun.COM> Date: Tue, 26 Oct 2004 10:30:18 +0200 From: Ludovic Poitou Organization: SUN Microsystems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: andrew.sciberras@eB2Bcom.com Subject: Re: [ldapext] Re: Password Policy for LDAP Directories References: <417D9565.5060607@eB2Bcom.com> In-Reply-To: <417D9565.5060607@eB2Bcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org, gabriele.garuglieri@infoblu.it, Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit I believe we all agree that from a security point of view, it is much better to have a fixed max age for the password and expiration regardless of whether warning was sent or not. Ludovic. Andrew Sciberras wrote: > Sorry Jim... I see where your coming from now :) > > Yep I agree. > > Andrew. > > Jim Sermersheim wrote: > >> Actually, I suggested that the password expire at its max age (regardles >> of whether any warnings have been sent). >> >> Jim >> >> >>>>> Andrew Sciberras 10/25/04 3:36:19 PM >>>>> >> >> G'Day >> >> I'm generally satisfied with this. >> >> If any directories exist today that use the following model: >> * pwdMaxAge - Absolute maximum age of the password >> * pwdExpireWarning - Time period before the max age in which warnings >> will be delivered, >> >> Then changing the semantics of these attributes would lead to >> unexpected behavior if an organization upgraded their directory >> server to the new >> >> functionality. >> >> Eg. A directory that wants to warn people 6 months before their >> password is due to expire. >> pwdMaxAge = 31536000 (1 year) >> pwdExpireWarning = 15768000 (6 Months) >> >> Updating the directory server to one that supports Jim's suggestion >> below will result in the password reaching its max age, then remaining >> >> valid for another 6 months. >> >> >> I'm not too sure if this is likely to be a serious problem for >> implementations, but some text in the security considerations of the >> draft indicating this might be appropriate. >> >> Cheers >> _________________________________________ >> Andrew Sciberras >> eB2Bcom - Software Engineer >> >> >> Jim Sermersheim wrote: >> >> >>> I believe the intent (however wrongly formulated) was to allow the >> >> >> user >> >>> to receive a warning no matter what. Even if the password's max age >> >> >> has >> >>> passed, the user would be allowed pwdExpireWarning seconds to change >> >> >> the >> >>> pwd. The definition of pwdExpireWarning talks about this in a not >> >> >> very >> >>> precise way (The number of seconds before the password will expire >> >> >> after >> >>> the user is first warned of its upcoming expiration.) >>> >>> Some history to help make sense of things: >>> >>> The password policy I-D was created as a blend of the (then) >> >> >> Netscape >> >>> and Novell directory password policies. >>> >>> I believe the original implementors of pwdExpireWarning (Netscape) >> >> >> used >> >>> this to both warn of expiration, and also allow some kind of grace >> >> >> login >> >>> period. >>> Novell's implementation didn't include the notion of a warning >> >> >> period. >> >>> Only a number of grace logins. >>> >>> So now we have two ways of achieving 'grace login'. >>> >>> A better way of specifying the pwdExpireWarning and pwdMaxAge >> >> >> concepts >> >>> would have been to use one attribute to specify an age at which an >>> expiration warning is sent, and another attribute specified how long >>> these warnings will continue before the password finally expires. >>> >>> I dislike having two similar but different grace mechanisms, so I >>> propose that we remove pwdExpireWarned, and expire the password when >> >> >> it >> >>> reaches pwdMaxAge (regardless of whether any warnings have been >> >> >> sent). >> >>> I'll update the I-D to reflect this without debate (because the >>> deadline is so near), and we can go from there. >>> >>> Jim >>> >>> >>> >>>>>> Andrew Sciberras < andrew.sciberras@eB2Bcom.com > 9/14/04 7:48:25 >>>>> >> >> PM >> >>> Hi Niel, >>> >>> >>> Neil Dunbar wrote: >>> >>> >>>> The pwdMaxAge should be the absolute maximum time that the password >>> >>> >>> can >>> >>> >>>> be used by anyone as a credential. The pwdExpirationWarning time, I >>>> think, should be the earliest opportunity that the directory server >>> >>> >>> can >>> >>> >>>> warn the user that his/her password is approaching expiry. If the >>> >>> >>> user >>> >>> >>>> comes into the expiry period late in the game - tough. You can >>> >>> >>> always >>> >>> >>>> use the grace logins feature to allow the user with the dud password >>> >>> >>> to >>> >>> >>>> change it after it has ceased to be a meaningful credential for >>> >>> >>> general >>> >>> >>>> directory operations >>> >>> >>> >>> >>> >>> If someone was to implement the draft in its current form, their >> >> >> first >> >>> warning time would indicate the time difference between the current >>> time and the time that the password is due to expire. Subsequent logins >>> would result in a warning time that will go beyond the specified >>> pwdMaxAge >> >> >> >>> allowing the user to receive their full warning period. >>> >>> Our implementation, which was based around the -05 version of the >> >> >> draft >> >>> handled this inconsistency by returning an initial warning message of >> >> >> >>> pwdExpireWarning. >>> >>> I've now noticed, in version -07 of the draft, that the following new >> >> >> >>> line exists within the description of pwdExpireWarning: >>> If not 0, the value must be smaller than the value of the pwdMaxAge >>> attribute. >>> >>> This seriously implies that the author's intention is to ensure that >>> the warning time does not exceed the maximum age of the password. >>> >>> I'm not extremely passionate about whether a user should receive >> >> >> their >> >>> full warning period. Some consensus on this issue, and the author's >>> opinion (Jim?) would be good though. >>> >>> >>> Andrew Sciberras >>> eB2Bcom - Software Engineer >>> >>> >>> >>> >>> >> >> ------------------------------------------------------------------------ >> >>> _______________________________________________ >>> Ldapext mailing list >>> Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext >> >> >> >> >> > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext -- Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Oct 26 05:10:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14408 for ; Tue, 26 Oct 2004 05:10:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMNHx-0002GC-Bq; Tue, 26 Oct 2004 05:06:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMNEZ-0001Mg-Df for ldapext@megatron.ietf.org; Tue, 26 Oct 2004 05:03:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13857 for ; Tue, 26 Oct 2004 05:03:12 -0400 (EDT) Received: from tobor.hpl.hp.com ([192.6.10.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMNSB-0006VT-QR for ldapext@ietf.org; Tue, 26 Oct 2004 05:17:20 -0400 Received: from localhost (localhost [127.0.0.1]) by tobor.hpl.hp.com (Postfix) with ESMTP id 64E463709F; Tue, 26 Oct 2004 10:03:13 +0100 (BST) Received: from tobor.hpl.hp.com ([127.0.0.1]) by localhost (tobor.hpl.hp.com [127.0.0.1]) (amavisd-new, port 20024) with LMTP id 17943-02-5; Tue, 26 Oct 2004 10:03:03 +0100 (BST) Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by tobor.hpl.hp.com (Postfix) with ESMTP id 2992337093; Tue, 26 Oct 2004 10:03:02 +0100 (BST) Received: from dunbar-n-1.hpl.hp.com (dunbar-n-1.hpl.hp.com [15.144.26.129]) by otter.hpl.hp.com (8.9.3 (PHNE_25183+JAGae58098)/HP-Labs Bristol Internal Mail Hub) with ESMTP id KAA29117; Tue, 26 Oct 2004 10:03:02 +0100 (BST) Subject: Re: [ldapext] Password Policy OIDs From: Neil Dunbar To: Jim Sermersheim In-Reply-To: References: Content-Type: text/plain Organization: Managed Directories, MSGD, HP Services Date: Tue, 26 Oct 2004 10:02:38 +0100 Message-Id: <1098781358.5584.6.camel@dunbar-n-1.hpl.hp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hplb.hpl.hp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: andrew.sciberras@eB2Bcom.com, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit On Mon, 2004-10-25 at 23:16 -0600, Jim Sermersheim wrote: > Yeah, I suppose we could do that as well. I'm looking at the > differences between the 00 version and the 09 version: > Andrew Sciberras wrote: > I think that this is a good idea, however your email suggests that > changing the OID's will disambiguate the semantics by which a > password > policy is being enforced. Do you plan to change the short name > descriptors of the attributes as well? > > Jim Sermersheim wrote: > > > This does bring up another point I wanted to discuss though... > > This draft was written way back when it was popular to assign OIDs > in > > I-D's. A practice that has lost favor partly due to implementations > > using those OIDs and experiencing problems as semantics changed but > OIDs > > didn't. Are we talking about replacing all OIDs, or just the schema OIDs? It seems that if we change the ones for the LDAP Request/Response controls then I can see a lot of implementations falling over (or at least failing to pass proper response information). Schema re-OIDing isn't that much of a hassle, for us at least. Cheers, Neil _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Oct 26 05:55:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17834 for ; Tue, 26 Oct 2004 05:55:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMO1K-0005Be-NU; Tue, 26 Oct 2004 05:53:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMNx5-0004Mt-Jg for ldapext@megatron.ietf.org; Tue, 26 Oct 2004 05:49:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17353 for ; Tue, 26 Oct 2004 05:49:13 -0400 (EDT) Received: from tobor.hpl.hp.com ([192.6.10.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMOAj-0007Kl-2G for ldapext@ietf.org; Tue, 26 Oct 2004 06:03:21 -0400 Received: from localhost (localhost [127.0.0.1]) by tobor.hpl.hp.com (Postfix) with ESMTP id 75E10370A5 for ; Tue, 26 Oct 2004 10:49:14 +0100 (BST) Received: from tobor.hpl.hp.com ([127.0.0.1]) by localhost (tobor.hpl.hp.com [127.0.0.1]) (amavisd-new, port 20024) with LMTP id 19748-01-8 for ; Tue, 26 Oct 2004 10:48:56 +0100 (BST) Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by tobor.hpl.hp.com (Postfix) with ESMTP id 8285B370A2 for ; Tue, 26 Oct 2004 10:48:36 +0100 (BST) Received: from dunbar-n-1.hpl.hp.com (dunbar-n-1.hpl.hp.com [15.144.26.129]) by otter.hpl.hp.com (8.9.3 (PHNE_25183+JAGae58098)/HP-Labs Bristol Internal Mail Hub) with ESMTP id KAA00994 for ; Tue, 26 Oct 2004 10:48:36 +0100 (BST) Subject: Re: [ldapext] Fwd: I-D ACTION:draft-behera-ldap-password-policy-08.txt From: Neil Dunbar To: ldapext@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: Managed Directories, MSGD, HP Services Date: Tue, 26 Oct 2004 10:48:12 +0100 Message-Id: <1098784092.5584.37.camel@dunbar-n-1.hpl.hp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hplb.hpl.hp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit On Mon, 2004-10-25 at 16:54 -0600, Jim Sermersheim wrote: > This update addresses some but not all concerns received to date. I > have 68 remaining mails left to get through. Couple of things: pwdExpirationWarned is now undefined, but is still referenced in section 8.2.7 and section 11. Section 11: The pwdAccountLockedTime, pwdExpirationWarned, pwdFailureTime and pwdGraceUseTime attributes MUST be replicated to writable replicas, making the password policy global for all servers. When the user entry is replicated to a read-only replica, these attributes SHOULD NOT be replicated. I'm not sure that this is a tenable position. I understand the difficulties (in effect, we're talking about making every server an LDAP master for just these operational attributes), but this seems to severely weaken the strength of the password policy. If a security officer approves a policy which states "5 guesses then you're out", I don't think he'll be thinking "Ah, but since there are 30 servers, that's really 150 guesses and you're out". I'm not sure how to express it properly, but I think I'd prefer something along the lines of A change to pwdFailureTime, pwdAccountLockedTime or pwdGraceUseTime occuring as the side-effect of a bind or compare operation SHOULD be propagated to a writeable server at the earliest opportunity after the local state has been updated. The pwdAccountLockedTime, pwdFailureTime and pwdGraceUseTime attributes MUST be replicated to all replicas. If the replication update would produce no change to the state of the target entry, then the update MAY be ignored. Changes to pwdAccountLockedTime, pwdFailureTime and pwdGraceUseTime which occur as part of a downstream replication MUST NOT be propagated to a writeable server. I think you need local state update, before you notify any master server of the change. To fail to do so would introduce a security flaw if you could DoS the update service (ie, the password would never get locked since the update to lock it would never happen). With the mechanism above I think you can say that *in the worst case* you'd end up with an NxM password guessing field. Whereas in the existing setup, the best case is also the same as the worst case. Cheers, Neil _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Oct 26 08:57:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02782 for ; Tue, 26 Oct 2004 08:57:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMQra-0007Bk-1t; Tue, 26 Oct 2004 08:55:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMQqg-0006xS-J2 for ldapext@megatron.ietf.org; Tue, 26 Oct 2004 08:54:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02563 for ; Tue, 26 Oct 2004 08:54:49 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMR4I-0002ZH-G1 for ldapext@ietf.org; Tue, 26 Oct 2004 09:08:57 -0400 Received: from odin.France.Sun.COM ([129.157.174.8]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9QCsiNH005647; Tue, 26 Oct 2004 06:54:45 -0600 (MDT) Received: from [129.157.211.132] (dhcp-gnb07-211-132 [129.157.211.132]) by odin.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9QCsiLi026146; Tue, 26 Oct 2004 14:54:44 +0200 (MEST) Message-ID: <417E48F7.9060408@Sun.COM> Date: Tue, 26 Oct 2004 14:54:15 +0200 From: Ludovic Poitou Organization: SUN Microsystems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Neil Dunbar Subject: Re: [ldapext] Fwd: I-D ACTION:draft-behera-ldap-password-policy-08.txt References: <1098784092.5584.37.camel@dunbar-n-1.hpl.hp.com> In-Reply-To: <1098784092.5584.37.camel@dunbar-n-1.hpl.hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit I believe that replication of these attributes should be a choice left to the administrator of the service and not mandated by the LDAP password policy specification. There are cases where replicating these attributes has a cost higher than the benefits. When the Directory Servers are behind a load balancer, applications need a consistent view. But when the service is geographically distributed and the authentications are mainly local to one server (with a possible failover), then keeping the attributes per server is really acceptable. The policy could be understood as "5 consecutive failed attempts on a machine and you're out of this machine" The goal of the policy is too limit the possibilities of a dictionary attack against a simple string based password, and should be balanced against a possible denial of service if all accounts are locked on all servers because someone is trying to authenticate with a known bad password. Ludovic. Neil Dunbar wrote: >On Mon, 2004-10-25 at 16:54 -0600, Jim Sermersheim wrote: > > >>This update addresses some but not all concerns received to date. I >>have 68 remaining mails left to get through. >> >> > >Couple of things: > >pwdExpirationWarned is now undefined, but is still referenced in section >8.2.7 and section 11. > >Section 11: > The pwdAccountLockedTime, pwdExpirationWarned, pwdFailureTime > and pwdGraceUseTime attributes MUST be replicated to writable > replicas, making the password policy global for all servers. > When the user entry is replicated to a read-only replica, these > attributes SHOULD NOT be replicated. > >I'm not sure that this is a tenable position. I understand the >difficulties (in effect, we're talking about making every server an LDAP >master for just these operational attributes), but this seems to >severely weaken the strength of the password policy. If a security >officer approves a policy which states "5 guesses then you're out", I >don't think he'll be thinking "Ah, but since there are 30 servers, >that's really 150 guesses and you're out". > >I'm not sure how to express it properly, but I think I'd prefer >something along the lines of > > A change to pwdFailureTime, pwdAccountLockedTime or > pwdGraceUseTime occuring as the side-effect of a bind or compare > operation SHOULD be propagated to a writeable server at the > earliest opportunity after the local state has been updated. The > pwdAccountLockedTime, pwdFailureTime and pwdGraceUseTime > attributes MUST be replicated to all replicas. If the > replication update would produce no change to the state of the > target entry, then the update MAY be ignored. Changes to > pwdAccountLockedTime, pwdFailureTime and pwdGraceUseTime which > occur as part of a downstream replication MUST NOT be propagated > to a writeable server. > >I think you need local state update, before you notify any master server >of the change. To fail to do so would introduce a security flaw if you >could DoS the update service (ie, the password would never get locked >since the update to lock it would never happen). With the mechanism >above I think you can say that *in the worst case* you'd end up with an >NxM password guessing field. Whereas in the existing setup, the best >case is also the same as the worst case. > >Cheers, > >Neil > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext > > -- Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Oct 26 09:00:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03008 for ; Tue, 26 Oct 2004 09:00:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMQua-0007qa-Pc; Tue, 26 Oct 2004 08:58:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMQtP-0007Tj-NC for ldapext@megatron.ietf.org; Tue, 26 Oct 2004 08:57:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02800 for ; Tue, 26 Oct 2004 08:57:38 -0400 (EDT) Received: from e6.ny.us.ibm.com ([32.97.182.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMR74-0002bz-L4 for ldapext@ietf.org; Tue, 26 Oct 2004 09:11:47 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9QCv8sZ098950 for ; Tue, 26 Oct 2004 08:57:08 -0400 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9QCv7qY265586 for ; Tue, 26 Oct 2004 08:57:07 -0400 In-Reply-To: <1098781358.5584.6.camel@dunbar-n-1.hpl.hp.com> Subject: Re: [ldapext] Password Policy OIDs To: ldapext@ietf.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: John McMeeking Date: Tue, 26 Oct 2004 07:57:05 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V70_M2_07222004 Beta 2|July 22, 2004) at 10/26/2004 07:57:07 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org I haven't looked to see how close the draft is to either the (then) Netscape or the Novell implementations, but here what I think: If the existing OIDs and descriptive names are based on password policy implementations that existed prior to this draft, I think the names and OIDs should be changed when the draft departs "far enough" from those existing implementations. At a minimum, I think the control OIDs ought to be different; that would make it possible for a client to determine which password policy implementation was supported by a server and act accordingly. If the OIDs and descriptive names in question are defined by the draft, I think it is reasonable for the draft to continue use those OIDs and names when it changes the semantics defined in a previous version. I think anyone implementing an Internet Draft is doing so at their own risk. Isn't that part of the rationale behind this statement? Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." John McMeeking neil.dunbar@hp.com wrote on 10/26/2004 04:02:38 AM: > On Mon, 2004-10-25 at 23:16 -0600, Jim Sermersheim wrote: > > Yeah, I suppose we could do that as well. I'm looking at the > > differences between the 00 version and the 09 version: > > > Andrew Sciberras wrote: > > I think that this is a good idea, however your email suggests that > > changing the OID's will disambiguate the semantics by which a > > password > > policy is being enforced. Do you plan to change the short name > > descriptors of the attributes as well? > > > > Jim Sermersheim wrote: > > > > > This does bring up another point I wanted to discuss though... > > > This draft was written way back when it was popular to assign OIDs > > in > > > I-D's. A practice that has lost favor partly due to implementations > > > using those OIDs and experiencing problems as semantics changed but > > OIDs > > > didn't. > > Are we talking about replacing all OIDs, or just the schema OIDs? It > seems that if we change the ones for the LDAP Request/Response controls > then I can see a lot of implementations falling over (or at least > failing to pass proper response information). > > Schema re-OIDing isn't that much of a hassle, for us at least. > > Cheers, > > Neil > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Oct 26 09:22:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04712 for ; Tue, 26 Oct 2004 09:22:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMREo-0003J8-Mx; Tue, 26 Oct 2004 09:19:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMREP-000381-5C for ldapext@megatron.ietf.org; Tue, 26 Oct 2004 09:19:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04449 for ; Tue, 26 Oct 2004 09:19:19 -0400 (EDT) Received: from gort.hpl.hp.com ([192.6.10.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMRS3-00031p-2T for ldapext@ietf.org; Tue, 26 Oct 2004 09:33:28 -0400 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by gort.hpl.hp.com (8.12.10/8.12.10) with ESMTP id i9QDI6j3010773; Tue, 26 Oct 2004 14:18:08 +0100 (BST) Received: from dunbar-n-1.hpl.hp.com (dunbar-n-1.hpl.hp.com [15.144.26.129]) by otter.hpl.hp.com (8.9.3 (PHNE_25183+JAGae58098)/HP-Labs Bristol Internal Mail Hub) with ESMTP id OAA08428; Tue, 26 Oct 2004 14:18:06 +0100 (BST) Subject: Re: [ldapext] Fwd: I-D ACTION:draft-behera-ldap-password-policy-08.txt From: Neil Dunbar To: Ludovic Poitou In-Reply-To: <417E48F7.9060408@Sun.COM> References: <1098784092.5584.37.camel@dunbar-n-1.hpl.hp.com> <417E48F7.9060408@Sun.COM> Content-Type: text/plain Organization: Managed Directories, MSGD, HP Services Date: Tue, 26 Oct 2004 14:17:42 +0100 Message-Id: <1098796662.28045.28.camel@dunbar-n-1.hpl.hp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit X-HPL-MailScanner-Information: Please contact the Helpdesk for more information X-HPL-MailScanner: Found to be clean X-HPL-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-1.437, required 5, autolearn=not spam, ALL_TRUSTED -0.84, AWL -0.59) X-MailScanner-From: neil.dunbar@hp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit On Tue, 2004-10-26 at 14:54 +0200, Ludovic Poitou wrote: > There are cases where replicating these attributes has a cost higher > than the benefits. > When the Directory Servers are behind a load balancer, applications need > a consistent view. > But when the service is geographically distributed and the > authentications are mainly local to one server (with a possible > failover), then keeping the attributes per server is really acceptable. > The policy could be understood as "5 consecutive failed attempts on a > machine and you're out of this machine" I see what you're saying - but what you're then doing is placing the semantics of an Information Security policy into the hands of the LDAP operations/design teams. I'm not sure too many InfoSec people would like that notion. In other words, if the LDAP ops team deploy another 20 servers, they're not going to ask their security teams to validate that installation - they're just going to do it. But that would have the effect of adding a boatload of extra guessing capability into the password protection mechanisms. If the rest of the passwords constraints aren't up to that, then you might well be compromising baseline security. I suppose you could always redirect binds from read-only replicas towards a writeable replica. That way you're guaranteed to maintain consistency across the domain. Similarly, I suppose you could use network segmentation to restrict the LDAP servers that you can bind to from a particular part of the network. I still think the draft should comment on the issues arising from replication, since it's far from obvious what needs to be done in all cases. Cheers, Neil _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Oct 26 10:59:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11555 for ; Tue, 26 Oct 2004 10:59:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMSl0-0001G2-1y; Tue, 26 Oct 2004 10:57:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMScC-0005fr-4E for ldapext@megatron.ietf.org; Tue, 26 Oct 2004 10:48:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10745 for ; Tue, 26 Oct 2004 10:47:57 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMSpo-0004TV-V5 for ldapext@ietf.org; Tue, 26 Oct 2004 11:02:08 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 26 Oct 2004 08:47:25 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Tue, 26 Oct 2004 08:46:59 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Password Policy OIDs Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: andrew.sciberras@eB2Bcom.com, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0458646697==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0458646697== Content-Type: multipart/alternative; boundary="=__Part47677573.2__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part47677573.2__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit >>> Neil Dunbar 10/26/04 3:02:38 AM >>> > >Are we talking about replacing all OIDs, or just the schema OIDs? It >seems that if we change the ones for the LDAP Request/Response controls >then I can see a lot of implementations falling over (or at least >failing to pass proper response information). > >Schema re-OIDing isn't that much of a hassle, for us at least. All of them. Without looking, I think the ASN.1 of the response control has been updated at least once. Jim --=__Part47677573.2__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>>> Neil Dunbar <neil.dunbar@hp.com> 10/26/04 3:02:38 = AM >>>
>
>Are we talking about replacing all OIDs, or = just the schema OIDs? It
>seems that if we change the ones for the = LDAP Request/Response controls
>then I can see a lot of implementatio= ns falling over (or at least
>failing to pass proper response = information).
>
>Schema re-OIDing isn't that much of a hassle, = for us at least.
All of them. Without looking, I think the ASN.1 of the response = control has been updated at least once.
 
Jim
--=__Part47677573.2__=-- --===============0458646697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0458646697==-- From ldapext-bounces@ietf.org Tue Oct 26 11:07:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12235 for ; Tue, 26 Oct 2004 11:07:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMSlX-0001Ur-H0; Tue, 26 Oct 2004 10:57:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMShC-00089I-K1 for ldapext@megatron.ietf.org; Tue, 26 Oct 2004 10:53:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11147 for ; Tue, 26 Oct 2004 10:53:08 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMSus-0004al-Q3 for ldapext@ietf.org; Tue, 26 Oct 2004 11:07:19 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 26 Oct 2004 08:52:39 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Tue, 26 Oct 2004 08:52:25 -0600 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] Fwd: I-D ACTION:draft-behera-ldap-password-policy-08.txt Mime-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1310799191==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============1310799191== Content-Type: multipart/alternative; boundary="=__Part8AAAB8B9.1__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part8AAAB8B9.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit >>> Neil Dunbar 10/26/04 3:48:12 AM >>> >On Mon, 2004-10-25 at 16:54 -0600, Jim Sermersheim wrote: >> This update addresses some but not all concerns received to date. I >> have 68 remaining mails left to get through. > >Couple of things: > >pwdExpirationWarned is now undefined, but is still referenced in section >8.2.7 and section 11. And one other place. I just fixed it in 09 Leaving the replication thing for another reply... JIm --=__Part8AAAB8B9.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>>> Neil Dunbar <neil.dunbar@hp.com> 10/26/04 3:48:12 = AM >>>
>On Mon, 2004-10-25 at 16:54 -0600, Jim Sermersheim = wrote:
>> This update addresses some but not all concerns = received to date. I
>> have 68 remaining mails left to get = through.
>
>Couple of things:
>
>pwdExpirationWarne= d is now undefined, but is still referenced in section
>8.2.7 and = section 11.
And one other place. I just fixed it in 09
 
Leaving the replication thing for another reply...
JIm
--=__Part8AAAB8B9.1__=-- --===============1310799191== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============1310799191==-- From ldapext-bounces@ietf.org Tue Oct 26 11:08:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12365 for ; Tue, 26 Oct 2004 11:08:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMSlf-0001gu-QD; Tue, 26 Oct 2004 10:57:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMSk6-0000oL-6s for ldapext@megatron.ietf.org; Tue, 26 Oct 2004 10:56:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11378 for ; Tue, 26 Oct 2004 10:56:07 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMSxl-0004eO-JS for ldapext@ietf.org; Tue, 26 Oct 2004 11:10:18 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 26 Oct 2004 08:55:37 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Tue, 26 Oct 2004 08:55:10 -0600 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] Fwd: I-D ACTION:draft-behera-ldap-password-policy-08.txt Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0506000910==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0506000910== Content-Type: multipart/alternative; boundary="=__Part6C4C5E5E.1__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part6C4C5E5E.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I agree. In fact, I think the draft needs to describe the "Replication Considerations", but not prescribe behavior. This leaves room for vendors and deployers to provide competitive solutions, and leaves the password policy draft out of the business of replication policies. Jim >>> Ludovic Poitou 10/26/04 6:54:15 AM >>> I believe that replication of these attributes should be a choice left to the administrator of the service and not mandated by the LDAP password policy specification. There are cases where replicating these attributes has a cost higher than the benefits. When the Directory Servers are behind a load balancer, applications need a consistent view. But when the service is geographically distributed and the authentications are mainly local to one server (with a possible failover), then keeping the attributes per server is really acceptable. The policy could be understood as "5 consecutive failed attempts on a machine and you're out of this machine" The goal of the policy is too limit the possibilities of a dictionary attack against a simple string based password, and should be balanced against a possible denial of service if all accounts are locked on all servers because someone is trying to authenticate with a known bad password. Ludovic. Neil Dunbar wrote: >On Mon, 2004-10-25 at 16:54 -0600, Jim Sermersheim wrote: > > >>This update addresses some but not all concerns received to date. I >>have 68 remaining mails left to get through. >> >> > >Couple of things: > >pwdExpirationWarned is now undefined, but is still referenced in section >8.2.7 and section 11. > >Section 11: > The pwdAccountLockedTime, pwdExpirationWarned, pwdFailureTime > and pwdGraceUseTime attributes MUST be replicated to writable > replicas, making the password policy global for all servers. > When the user entry is replicated to a read-only replica, these > attributes SHOULD NOT be replicated. > >I'm not sure that this is a tenable position. I understand the >difficulties (in effect, we're talking about making every server an LDAP >master for just these operational attributes), but this seems to >severely weaken the strength of the password policy. If a security >officer approves a policy which states "5 guesses then you're out", I >don't think he'll be thinking "Ah, but since there are 30 servers, >that's really 150 guesses and you're out". > >I'm not sure how to express it properly, but I think I'd prefer >something along the lines of > > A change to pwdFailureTime, pwdAccountLockedTime or > pwdGraceUseTime occuring as the side-effect of a bind or compare > operation SHOULD be propagated to a writeable server at the > earliest opportunity after the local state has been updated. The > pwdAccountLockedTime, pwdFailureTime and pwdGraceUseTime > attributes MUST be replicated to all replicas. If the > replication update would produce no change to the state of the > target entry, then the update MAY be ignored. Changes to > pwdAccountLockedTime, pwdFailureTime and pwdGraceUseTime which > occur as part of a downstream replication MUST NOT be propagated > to a writeable server. > >I think you need local state update, before you notify any master server >of the change. To fail to do so would introduce a security flaw if you >could DoS the update service (ie, the password would never get locked >since the update to lock it would never happen). With the mechanism >above I think you can say that *in the worst case* you'd end up with an >NxM password guessing field. Whereas in the existing setup, the best >case is also the same as the worst case. > >Cheers, > >Neil > > >_______________________________________________ >Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > > -- Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__Part6C4C5E5E.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree. In fact, I think the draft needs to describe the "Replication= Considerations", but not prescribe behavior.
 
This leaves room for vendors and deployers to provide competitive = solutions, and leaves the password policy draft out of the business of = replication policies.
 
Jim

>>> Ludovic Poitou <ludovic.poitou@Sun.COM> = 10/26/04 6:54:15 AM >>>
I believe that replication of these = attributes should be a choice left
to the administrator of the service = and not mandated by the LDAP
password policy specification.
There = are cases where replicating these attributes has a cost higher
than = the benefits.
When the Directory Servers are behind a load balancer, = applications need
a consistent view.
But when the service is = geographically distributed and the
authentications are mainly local to = one server (with a possible
failover), then keeping the attributes per = server is really acceptable.
The policy could be understood as "5 = consecutive failed attempts on a
machine and you're out of this = machine"

The goal of the policy is too limit the possibilities of a = dictionary
attack against a simple string based password, and should = be balanced
against a possible denial of service if all accounts are = locked on all
servers because someone is trying to authenticate with a = known bad password.

Ludovic.

Neil Dunbar wrote:

>On= Mon, 2004-10-25 at 16:54 -0600, Jim Sermersheim wrote:
>
>>>This update addresses some but not all concerns received to date. = I
>>have 68 remaining mails left to get through.
>> =
>>
>
>Couple of things:
>
>pwdExpirationW= arned is now undefined, but is still referenced in section
>8.2.7 = and section 11.
>
>Section 11:
> The pwdAccountLockedTime= , pwdExpirationWarned, pwdFailureTime
> and pwdGraceUseTime = attributes MUST be replicated to writable
> replicas, making the = password policy global for all servers.
> When the user entry is = replicated to a read-only replica, these
> attributes SHOULD NOT be = replicated.
>
>I'm not sure that this is a tenable position. = I understand the
>difficulties (in effect, we're talking about = making every server an LDAP
>master for just these operational = attributes), but this seems to
>severely weaken the strength of the = password policy. If a security
>officer approves a policy which = states "5 guesses then you're out", I
>don't think he'll be thinking = "Ah, but since there are 30 servers,
>that's really 150 guesses and = you're out".
>
>I'm not sure how to express it properly, but I = think I'd prefer
>something along the lines of
>
> A = change to pwdFailureTime, pwdAccountLockedTime or
> pwdGraceUseTime = occuring as the side-effect of a bind or compare
> operation SHOULD = be propagated to a writeable server at the
> earliest opportunity = after the local state has been updated. The
> pwdAccountLockedTime, = pwdFailureTime and pwdGraceUseTime
> attributes MUST be replicated = to all replicas. If the
> replication update would produce no change = to the state of the
> target entry, then the update MAY be ignored. = Changes to
> pwdAccountLockedTime, pwdFailureTime and pwdGraceUseTime= which
> occur as part of a downstream replication MUST NOT be = propagated
> to a writeable server.
>
>I think you need = local state update, before you notify any master server
>of the = change. To fail to do so would introduce a security flaw if you
>coul= d DoS the update service (ie, the password would never get locked
>si= nce the update to lock it would never happen). With the mechanism
>ab= ove I think you can say that *in the worst case* you'd end up with = an
>NxM password guessing field. Whereas in the existing setup, the = best
>case is also the same as the worst case.
>
>Cheers,=
>
>Neil
>
>
>_______________________________= ________________
>Ldapext mailing list
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinf= o/ldapext
>
>

--
Ludovic Poitou
Directo= ry Architect.
Directory Server Group, Grenoble, France
Sun Microsyste= ms Inc.

Sun Microsystems requires the following notice:
~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This = email message is for the sole use of the intended
recipient(s) and may = contain confidential and privileged
information. Any unauthorized = review, use, disclosure or
distribution is prohibited. If you are not = the intended
recipient, please contact the sender by reply email and = destroy
all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


__________________________= _____________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext=
--=__Part6C4C5E5E.1__=-- --===============0506000910== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0506000910==-- From ldapext-bounces@ietf.org Tue Oct 26 11:13:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12794 for ; Tue, 26 Oct 2004 11:13:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMSvs-0005vs-Qv; Tue, 26 Oct 2004 11:08:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMSq5-0003pP-HN for ldapext@megatron.ietf.org; Tue, 26 Oct 2004 11:02:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11753 for ; Tue, 26 Oct 2004 11:02:19 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMT3l-0004lr-MN for ldapext@ietf.org; Tue, 26 Oct 2004 11:16:30 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 26 Oct 2004 09:01:50 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Tue, 26 Oct 2004 09:01:29 -0600 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] Password Policy OIDs Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1579572463==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============1579572463== Content-Type: multipart/alternative; boundary="=__PartE8C8DAD9.0__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartE8C8DAD9.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit >>> John McMeeking 10/26/04 6:57:05 AM >>> >I haven't looked to see how close the draft is to either the (then) >Netscape or the Novell implementations, but here what I think: > >If the existing OIDs and descriptive names are based on password policy >implementations that existed prior to this draft, I think the names and >OIDs should be changed when the draft departs "far enough" from those >existing implementations. At a minimum, I think the control OIDs ought to >be different; that would make it possible for a client to determine which >password policy implementation was supported by a server and act >accordingly. The draft probably drifted 'far enough' from both the Novell and Netscape implementations in the -00 version. The concern is probably how far has it drifted (or will it drift) from where it was when other vendors (OpenLDAP, eB2B, and others) started implementing it? >If the OIDs and descriptive names in question are defined by the draft, I >think it is reasonable for the draft to continue use those OIDs and names >when it changes the semantics defined in a previous version. I think >anyone implementing an Internet Draft is doing so at their own risk. Isn't >that part of the rationale behind this statement? > >Internet-Drafts are draft documents valid for a maximum of six >months and may be updated, replaced, or obsoleted by other documents >at any time. It is inappropriate to use Internet-Drafts as >reference material or to cite them other than as "work in progress." Yes, you're exactly right. There is technically no problem with us retaining the OIDs and wildly changing semantics or definitions. Early adopters should have used their own OIDs (and descriptors) to begin with. My guess (I have no evidence) is that early implementors have used the specified OIDs and names, and I want to make life easy on them as well make the I-D as easy to update. Jim --=__PartE8C8DAD9.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>>> John McMeeking <jmcmeek@us.ibm.com> 10/26/04 = 6:57:05 AM >>>
>I haven't looked to see how close the draft = is to either the (then)
>Netscape or the Novell implementations, but = here what I think:
>
>If the existing OIDs and descriptive = names are based on password policy
>implementations that existed = prior to this draft, I think the names and
>OIDs should be changed = when the draft departs "far enough" from those
>existing implementati= ons. At a minimum, I think the control OIDs ought to
>be different; = that would make it possible for a client to determine which
>password= policy implementation was supported by a server and act
>accordingly= .
The draft probably drifted 'far enough' from both the Novell and = Netscape implementations in the -00 version. The concern is probably how = far has it drifted (or will it drift) from where it was when other vendors = (OpenLDAP, eB2B, and others) started implementing it?

>If the OIDs and descriptive names in question are defined by = the draft, I
>think it is reasonable for the draft to continue use = those OIDs and names
>when it changes the semantics defined in a = previous version. I think
>anyone implementing an Internet Draft is = doing so at their own risk. Isn't
>that part of the rationale behind = this statement?
>
>Internet-Drafts are draft documents valid for a maximum of = six
>months and may be updated, replaced, or obsoleted by other = documents
>at any time. It is inappropriate to use Internet-Drafts = as
>reference material or to cite them other than as "work in = progress."
Yes, you're exactly right. There is technically no problem with us = retaining the OIDs and wildly changing semantics or definitions. Early = adopters should have used their own OIDs (and descriptors) to begin with. = My guess (I have no evidence) is that early implementors have used the = specified OIDs and names, and I want to make life easy on them as = well make the I-D as easy to update.

Jim
--=__PartE8C8DAD9.0__=-- --===============1579572463== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============1579572463==-- From ldapext-bounces@ietf.org Tue Oct 26 11:52:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17569 for ; Tue, 26 Oct 2004 11:52:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMTXc-0005yb-B0; Tue, 26 Oct 2004 11:47:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMTT4-0004zv-3k for ldapext@megatron.ietf.org; Tue, 26 Oct 2004 11:42:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16552 for ; Tue, 26 Oct 2004 11:42:35 -0400 (EDT) Received: from colossus.hpl.hp.com ([192.6.10.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMTgk-0005rq-8u for ldapext@ietf.org; Tue, 26 Oct 2004 11:56:46 -0400 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by colossus.hpl.hp.com (8.12.10/8.12.10) with ESMTP id i9QFgEh4028690 for ; Tue, 26 Oct 2004 16:42:14 +0100 (BST) Received: from dunbar-n-1.hpl.hp.com (dunbar-n-1.hpl.hp.com [15.144.26.129]) by otter.hpl.hp.com (8.9.3 (PHNE_25183+JAGae58098)/HP-Labs Bristol Internal Mail Hub) with ESMTP id QAA13374 for ; Tue, 26 Oct 2004 16:42:13 +0100 (BST) Subject: Re: [ldapext] Password Policy OIDs From: Neil Dunbar To: LDAP Extension Mailing List In-Reply-To: References: Content-Type: text/plain Organization: Managed Directories, MSGD, HP Services Date: Tue, 26 Oct 2004 16:41:49 +0100 Message-Id: <1098805309.28045.44.camel@dunbar-n-1.hpl.hp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit X-HPL-MailScanner-Information: Please contact the helpdesk for more information X-HPL-MailScanner: Found to be clean X-HPL-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-1.47, required 5, autolearn=not spam, ALL_TRUSTED -0.84, AWL -0.63) X-MailScanner-From: neil.dunbar@hp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit On Tue, 2004-10-26 at 09:01 -0600, Jim Sermersheim wrote: > The draft probably drifted 'far enough' from both the Novell and > Netscape implementations in the -00 version. The concern is probably > how far has it drifted (or will it drift) from where it was when other > vendors (OpenLDAP, eB2B, and others) started implementing it? The OpenLDAP one (my prototype, Howard Chu's code) is based on draft -07, so the level of drift should be pretty small.I don't think anyone will die if the OIDs change - certainly the level of deployment within HP is sufficiently small not to cause major headaches. And yes - I agree with John's point that you implement I-Ds at your own risk. Cheers, Neil _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Oct 26 11:56:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17892 for ; Tue, 26 Oct 2004 11:56:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMTcQ-0007Em-4c; Tue, 26 Oct 2004 11:52:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMTZu-0006b5-N2 for ldapext@megatron.ietf.org; Tue, 26 Oct 2004 11:49:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17328 for ; Tue, 26 Oct 2004 11:49:40 -0400 (EDT) Received: from tobor.hpl.hp.com ([192.6.10.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMTna-00064r-Av for ldapext@ietf.org; Tue, 26 Oct 2004 12:03:51 -0400 Received: from localhost (localhost [127.0.0.1]) by tobor.hpl.hp.com (Postfix) with ESMTP id 9123A370A8 for ; Tue, 26 Oct 2004 16:49:40 +0100 (BST) Received: from tobor.hpl.hp.com ([127.0.0.1]) by localhost (tobor.hpl.hp.com [127.0.0.1]) (amavisd-new, port 20024) with LMTP id 01666-01-4 for ; Tue, 26 Oct 2004 16:49:19 +0100 (BST) Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by tobor.hpl.hp.com (Postfix) with ESMTP id F12C5370AC for ; Tue, 26 Oct 2004 16:49:16 +0100 (BST) Received: from dunbar-n-1.hpl.hp.com (dunbar-n-1.hpl.hp.com [15.144.26.129]) by otter.hpl.hp.com (8.9.3 (PHNE_25183+JAGae58098)/HP-Labs Bristol Internal Mail Hub) with ESMTP id QAA13613 for ; Tue, 26 Oct 2004 16:49:16 +0100 (BST) Subject: Re: [ldapext] Fwd: I-D ACTION:draft-behera-ldap-password-policy-08.txt From: Neil Dunbar To: LDAP Extension Mailing List In-Reply-To: References: Content-Type: text/plain Organization: Managed Directories, MSGD, HP Services Date: Tue, 26 Oct 2004 16:48:52 +0100 Message-Id: <1098805732.28045.51.camel@dunbar-n-1.hpl.hp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hplb.hpl.hp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit On Tue, 2004-10-26 at 08:55 -0600, Jim Sermersheim wrote: > I agree. In fact, I think the draft needs to describe the "Replication > Considerations", but not prescribe behavior. > > This leaves room for vendors and deployers to provide competitive > solutions, and leaves the password policy draft out of the business of > replication policies. Yup. On consideration, you're right. Protocol descriptions aren't where security architecture discussions belong. Forget the changed text - it seems to me that you could have a thoroughly replicated policy and still fit within the considerations given. Cheers, Neil _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Oct 26 12:06:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18683 for ; Tue, 26 Oct 2004 12:06:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMTmX-00018b-9F; Tue, 26 Oct 2004 12:02:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMTlc-0000uy-BY for ldapext@megatron.ietf.org; Tue, 26 Oct 2004 12:01:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18369 for ; Tue, 26 Oct 2004 12:01:45 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMTzI-0006M7-3y for ldapext@ietf.org; Tue, 26 Oct 2004 12:15:57 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 26 Oct 2004 10:01:16 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Tue, 26 Oct 2004 10:00:50 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Duane Buss , Hal Henderson , Tammy Green Subject: [ldapext] Splitting Password Policy X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1472227973==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============1472227973== Content-Type: multipart/alternative; boundary="=__Part81A1B3A2.0__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part81A1B3A2.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit All, Speaking on behalf of some people on the CC list, it is seen as desirable to place password update policy in one specification, and place password use policy in another specification. This started as an act of associating password use policy (such as intruder detection policy) with login policy (such as allowable login times, addresses, etc). It then diverged from that and ended up being described as: Password policy is policy that applies only to simple bind passwords. Login policy involves policy that can be applied to *any* kind of credentials. My argument was that policy like password expiration (while enforced at authN time) is intimately tied to password updates. Thus, if we were to split this into two I-Ds, there would be some amount of cross referencing, and cross requirements (password expiration would require actions during password update). I know some people in the community have asked for more "login policy" type things to be added to the I-D, and we've pushed against adding those. What are other's feelings in this area? (Tammy, Duane, Hal, feel free to clarify these positions). Jim --=__Part81A1B3A2.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,
 
Speaking on behalf of some people on the CC list, it is seen as = desirable to place password update policy in one specification, and = place password use policy in another specification.
 
This started as an act of associating password use policy (such as = intruder detection policy) with login policy (such as allowable login = times, addresses, etc).
 
It then diverged from that and ended up being described as: Password = policy is policy that applies only to simple bind passwords. Login policy = involves policy that can be applied to *any* kind of credentials.
 
My argument was that policy like password expiration (while enforced = at authN time) is intimately tied to password updates. Thus, if we = were to split this into two I-Ds, there would be some amount of cross = referencing, and cross requirements (password expiration would require = actions during password update).
 
I know some people in the community have asked for more "login = policy" type things to be added to the I-D, and we've pushed against = adding those.
 
What are other's feelings in this area? (Tammy, Duane, Hal, feel free = to clarify these positions).
 
Jim
--=__Part81A1B3A2.0__=-- --===============1472227973== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============1472227973==-- From ldapext-bounces@ietf.org Tue Oct 26 12:24:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20294 for ; Tue, 26 Oct 2004 12:24:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMU5u-0006zu-Tk; Tue, 26 Oct 2004 12:22:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMU4B-0006cb-1p for ldapext@megatron.ietf.org; Tue, 26 Oct 2004 12:20:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19937 for ; Tue, 26 Oct 2004 12:20:56 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMUHr-0006kU-Rj for ldapext@ietf.org; Tue, 26 Oct 2004 12:35:08 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9QGKsZv053943; Tue, 26 Oct 2004 16:20:54 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041026091821.02e198d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 26 Oct 2004 09:21:25 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Splitting Password Policy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Duane Buss , Hal Henderson , ldapext@ietf.org, Tammy Green X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Just a thought, but it might also be useful to split the protocol elements from the schema elements. The protocol controls could be genericized to support expiration of other kinds of credentials. At 09:00 AM 10/26/2004, Jim Sermersheim wrote: >All, > >Speaking on behalf of some people on the CC list, it is seen as desirable to place password update policy in one specification, and place password use policy in another specification. > >This started as an act of associating password use policy (such as intruder detection policy) with login policy (such as allowable login times, addresses, etc). > >It then diverged from that and ended up being described as: Password policy is policy that applies only to simple bind passwords. Login policy involves policy that can be applied to *any* kind of credentials. > >My argument was that policy like password expiration (while enforced at authN time) is intimately tied to password updates. Thus, if we were to split this into two I-Ds, there would be some amount of cross referencing, and cross requirements (password expiration would require actions during password update). > >I know some people in the community have asked for more "login policy" type things to be added to the I-D, and we've pushed against adding those. > >What are other's feelings in this area? (Tammy, Duane, Hal, feel free to clarify these positions). > >Jim >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Oct 26 20:38:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14692 for ; Tue, 26 Oct 2004 20:38:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMbZZ-00076o-Bg; Tue, 26 Oct 2004 20:21:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMaDS-0007BQ-5u for ldapext@megatron.ietf.org; Tue, 26 Oct 2004 18:54:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19212 for ; Tue, 26 Oct 2004 18:54:54 -0400 (EDT) Received: from amos.eb2b.com.au ([210.8.191.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMaRA-0007eE-Hh for ldapext@ietf.org; Tue, 26 Oct 2004 19:09:09 -0400 Received: from [192.168.1.155] (210.8.191.250) by amos.eb2b.com.au (7.1.016.1) (authenticated as andrew.sciberras) id 416CAD380000172C; Wed, 27 Oct 2004 09:02:51 +1000 Message-ID: <417ED549.2080203@eB2Bcom.com> Date: Wed, 27 Oct 2004 08:52:57 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-au, en-gb, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: Ldapext Subject: [ldapext] draft-zeilenga-ldap-readentry-03.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew.sciberras@eB2Bcom.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Kurt, Section 1. "The extension utilizes controls [Protocol] attached update requests to request and return copies of the target entry." Insert a 'to' between 'attached' and 'update'. Now, the last thing I want to do is get into a discussion about the criticality of controls, since we've been over this a number of times. However, two statements exist which leave me puzzled: "The normal processing of the update operation and the processing of this control MUST be performed as one atomic action isolated from other update operations." "The criticality may be TRUE or FALSE." So, the operation MUST be atomic and the control may have a criticality of FALSE. What would happen if a DSA received a modifyRequest with a controlType whose value is IANA-ASSIGNED-OID.1 and a controlValue of an empty OCTET STRING and a criticality of FALSE? The DSA: * recognizes the control (and supports it), * is aware of the atomic nature of this request, * cannot decode the controlValue * Can rightfully ignore the control since it's not critical Does the DSA fail the operation (for atomic reasons) or proceed (based on the criticality)? I don't know the right answer... but would be inclined to state that this control should not change the LDAP semantics of the criticality field of the control and therefore continue processing. Cheers, _________________________________________ Andrew Sciberras eB2Bcom - Software Engineer _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Oct 26 20:47:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15803 for ; Tue, 26 Oct 2004 20:47:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMbfi-0000kT-DO; Tue, 26 Oct 2004 20:28:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMb23-0006Mp-L2 for ldapext@megatron.ietf.org; Tue, 26 Oct 2004 19:47:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01313 for ; Tue, 26 Oct 2004 19:47:12 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMbFn-0003TZ-4Q for ldapext@ietf.org; Tue, 26 Oct 2004 20:01:28 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9QN4ZZv056199; Tue, 26 Oct 2004 23:04:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041026155748.02f1ae20@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 26 Oct 2004 16:05:05 -0700 To: andrew.sciberras@eB2Bcom.com From: "Kurt D. Zeilenga" In-Reply-To: <417ED549.2080203@eB2Bcom.com> References: <417ED549.2080203@eB2Bcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Ldapext Subject: [ldapext] Re: draft-zeilenga-ldap-readentry-03.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 03:52 PM 10/26/2004, Andrew Sciberras wrote: >Now, the last thing I want to do is get into a discussion about the criticality of controls, since we've been over this a number of times. However, two statements exist which leave me puzzled: > >"The normal processing of the update operation and the processing of >this control MUST be performed as one atomic action isolated from >other update operations." > >"The criticality may be TRUE or FALSE." > > >So, the operation MUST be atomic and the control may have a criticality of FALSE. >What would happen if a DSA received a modifyRequest with a controlType whose value is IANA-ASSIGNED-OID.1 and a controlValue of an empty OCTET STRING and a criticality of FALSE? >The DSA: > * recognizes the control (and supports it), and, if its appropriate for the request, "the server will make use of the control when performing the operation." > * is aware of the atomic nature of this request, > * cannot decode the controlValue > * Can rightfully ignore the control since it's not critical IMO, the server cannot rightfully ignore the control regardless of its criticality. >Does the DSA fail the operation (for atomic reasons) or proceed (based on the criticality)? Fail. Assuming the decode problem is due to violation of the control's technical specification, protocolError would likely be the most appropriate code to return. There are, of course, numerous other ways the server could fail to decode the controlValue or be otherwise not willing or able to perform the operation. Whatever the case, the server should fail the operation and return an appropriate error code. >I don't know the right answer... but would be inclined to state that this control should not change the LDAP semantics of the criticality field of the control and therefore continue processing. I would argue that control semantics (as defined by RFC 2251) are that the value of the criticality field are irrelevant in this case as "the server recognizes the control type and it is appropriate for the operation" and hence is obligated to "make use of the control when performing the operation" (or fail the operation). Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Oct 27 03:05:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11163 for ; Wed, 27 Oct 2004 03:05:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMhpa-0001CV-6a; Wed, 27 Oct 2004 03:02:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMhoT-0000vf-Aa for ldapext@megatron.ietf.org; Wed, 27 Oct 2004 03:01:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10826 for ; Wed, 27 Oct 2004 03:01:39 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMi2H-0006uw-I3 for ldapext@ietf.org; Wed, 27 Oct 2004 03:15:58 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 27 Oct 2004 01:01:09 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Wed, 27 Oct 2004 01:00:34 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Re: Password Policy for LDAP Directories Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: andrew.sciberras@eB2Bcom.com, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0587642587==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0587642587== Content-Type: multipart/alternative; boundary="=__Part93B3A082.2__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part93B3A082.2__= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Correct (sort of). It will be (pwdChangedTime + pwdMaxAge) - current time. =20 Jim >>> Gabriele Garuglieri 10/27/04 12:09:46 = AM >>> Hi all, i agree with that, it make sense. I think this imply that when we are in the pwdExpireWarning period, the=20 PasswordPolicyResponseValue, timeBeforeExpiration will always have the=20 predictable value of pwdMaxAge - current time, does it? Regards, Gabriele. Jim Sermersheim wrote: > I believe the intent (however wrongly formulated) was to allow the=20 > user to receive a warning no matter what. Even if the password's max=20 > age has passed, the user would be allowed pwdExpireWarning seconds to=20 > change the pwd. The definition of pwdExpireWarning talks about this = in=20 > a not very precise way (The number of seconds before the password = will=20 > expire after the user is first warned of its upcoming expiration.) >=20 > Some history to help make sense of things: >=20 > The password policy I-D was created as a blend of the (then) Netscape=20 > and Novell directory password policies. >=20 > I believe the original implementors of pwdExpireWarning (Netscape)=20 > used this to both warn of expiration, and also allow some kind of=20 > grace login period. > Novell's implementation didn't include the notion of a warning period.=20= > Only a number of grace logins. >=20 > So now we have two ways of achieving 'grace login'. >=20 > A better way of specifying the pwdExpireWarning and pwdMaxAge concepts=20= > would have been to use one attribute to specify an age at which an=20 > expiration warning is sent, and another attribute specified how long=20 > these warnings will continue before the password finally expires. >=20 > I dislike having two similar but different grace mechanisms, so I=20 > propose that we remove pwdExpireWarned, and expire the password when=20 > it reaches pwdMaxAge (regardless of whether any warnings have been = sent). >=20 > I'll update the I-D to reflect this without debate (because the=20 > deadline is so near), and we can go from there. >=20 > Jim > > >>> Andrew Sciberras < andrew.sciberras@eB2Bcom.com > 9/14/04 7:48:25 PM = >>> > Hi Niel, > > > Neil Dunbar wrote: > > > The pwdMaxAge should be the absolute maximum time that the password = can > > be used by anyone as a credential. The pwdExpirationWarning time, I > > think, should be the earliest opportunity that the directory server = can > > warn the user that his/her password is approaching expiry. If the user > > comes into the expiry period late in the game - tough. You can always > > use the grace logins feature to allow the user with the dud password = to > > change it after it has ceased to be a meaningful credential for = general > > directory operations > > > > If someone was to implement the draft in its current form, their first > warning time would indicate the time difference between the current time > and the time that the password is due to expire. Subsequent logins would > result in a warning time that will go beyond the specified pwdMaxAge > allowing the user to receive their full warning period. > > Our implementation, which was based around the -05 version of the draft > handled this inconsistency by returning an initial warning message of > pwdExpireWarning. > > I've now noticed, in version -07 of the draft, that the following new > line exists within the description of pwdExpireWarning: > If not 0, the value must be smaller than the value of the pwdMaxAge > attribute. > > This seriously implies that the author's intention is to ensure that the > warning time does not exceed the maximum age of the password. > > I'm not extremely passionate about whether a user should receive their > full warning period. Some consensus on this issue, and the author's > opinion (Jim?) would be good though. > > > Andrew Sciberras > eB2Bcom - Software Engineer --=20 =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0= =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0 =B0 Gabriele Garuglieri =B0 =B0 Infoblu S.p.A =B0 =B0 c/o Nuovo Centro Direzionale =B0 =B0 Autostrade // per l'Italia =B0 =B0 svincolo autostradale Firenze Nord =B0=20 =B0 50013 Campi Bisenzio - Firenze =B0 =B0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =B0 =B0 email: gabriele.garuglieri@infoblu.it =B0 =B0 phone: +390554202832 =B0 =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0= =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=20 --=__Part93B3A082.2__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Correct (sort of). It will be (pwdChangedTime + pwdMaxAge) - current = time.
 
Jim

>>> Gabriele Garuglieri <gabriele.garuglieri@in= foblu.it> 10/27/04 12:09:46 AM >>>
Hi all,
i agree with = that, it make sense.
I think this imply that when we are in the = pwdExpireWarning period, the
PasswordPolicyResponseValue, timeBeforeExp= iration will always have the
predictable value of pwdMaxAge - current = time, does it?
Regards, Gabriele.

Jim Sermersheim wrote:

&= gt; I believe the intent (however wrongly formulated) was to allow the =
> user to receive a warning no matter what. Even if the password's = max
> age has passed, the user would be allowed pwdExpireWarning = seconds to
> change the pwd. The definition of pwdExpireWarning = talks about this in
> a not very precise way (The number of seconds = before the password will
> expire after the user is first warned of = its upcoming expiration.)
>
> Some history to help make sense = of things:
>
> The password policy I-D was created as a blend = of the (then) Netscape
> and Novell directory password policies.
= >
> I believe the original implementors of pwdExpireWarning = (Netscape)
> used this to both warn of expiration, and also allow = some kind of
> grace login period.
> Novell's implementation = didn't include the notion of a warning period.
> Only a number of = grace logins.
>
> So now we have two ways of achieving 'grace = login'.
>
> A better way of specifying the pwdExpireWarning = and pwdMaxAge concepts
> would have been to use one attribute to = specify an age at which an
> expiration warning is sent, and = another attribute specified how long
> these warnings will continue = before the password finally expires.
>
> I dislike having two = similar but different grace mechanisms, so I
> propose that we = remove pwdExpireWarned, and expire the password when
> it reaches = pwdMaxAge (regardless of whether any warnings have been sent).
> =
> I'll update the I-D to reflect this without debate (because the =
> deadline is so near), and we can go from there.
>
> = Jim
>
> >>> Andrew Sciberras < andrew.sciberras@eB2Bcom.com > = 9/14/04 7:48:25 PM >>>
> Hi Niel,
>
>
> = Neil Dunbar wrote:
> <SNIP>
> > The pwdMaxAge should = be the absolute maximum time that the password can
> > be used by = anyone as a credential. The pwdExpirationWarning time, I
> > = think, should be the earliest opportunity that the directory server = can
> > warn the user that his/her password is approaching = expiry. If the user
> > comes into the expiry period late in the = game - tough. You can always
> > use the grace logins feature to = allow the user with the dud password to
> > change it after it = has ceased to be a meaningful credential for general
> > = directory operations
> </SNIP>
>
>
> If = someone was to implement the draft in its current form, their first
>= warning time would indicate the time difference between the current = time
> and the time that the password is due to expire. Subsequent = logins would
> result in a warning time that will go beyond the = specified pwdMaxAge
> allowing the user to receive their full = warning period.
>
> Our implementation, which was based around = the -05 version of the draft
> handled this inconsistency by = returning an initial warning message of
> pwdExpireWarning.
>> I've now noticed, in version -07 of the draft, that the following = new
> line exists within the description of pwdExpireWarning:
>= If not 0, the value must be smaller than the value of the pwdMaxAge
>= ; attribute.
>
> This seriously implies that the author's = intention is to ensure that the
> warning time does not exceed the = maximum age of the password.
>
> I'm not extremely passionate = about whether a user should receive their
> full warning period. = Some consensus on this issue, and the author's
> opinion (Jim?) = would be good though.
>
>
> Andrew Sciberras
> = eB2Bcom - Software Engineer


--
=B0=B0=B0=B0=B0=B0=B0=B0=B0= =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0= =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0
=B0 Gabriele Garuglieri =B0
=B0 = Infoblu S.p.A =B0
=B0 c/o Nuovo Centro Direzionale =B0
=B0 Autostrade= // per l'Italia =B0
=B0 svincolo autostradale Firenze Nord =B0
=B0 = 50013 Campi Bisenzio - Firenze =B0
=B0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =B0
=B0 email: gabriele.garuglieri@infoblu.it =B0
=B0 phone: = +390554202832 =B0
=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0= =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0= =B0


--=__Part93B3A082.2__=-- --===============0587642587== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0587642587==-- From ldapext-bounces@ietf.org Wed Oct 27 13:53:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27028 for ; Wed, 27 Oct 2004 13:53:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMryE-0005Vj-5B; Wed, 27 Oct 2004 13:52:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMrru-0004ba-Jg for ldapext@megatron.ietf.org; Wed, 27 Oct 2004 13:45:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26549 for ; Wed, 27 Oct 2004 13:45:52 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMs5o-0002oD-Im for ldapext@ietf.org; Wed, 27 Oct 2004 14:00:17 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 27 Oct 2004 11:45:22 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Wed, 27 Oct 2004 11:45:00 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Subject: [ldapext] Re: I-D ACTION:draft-zeilenga-ldap-adlist-09.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0098236887==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0098236887== Content-Type: multipart/alternative; boundary="=__Part0424378C.0__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part0424378C.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Kurt, This specifies that the class is expanded to all MUST, and MAY attributes of the class, (either directly or inherited). Does it also include (and exclude) attributes specified in the DITContentRule for structural classes? Jim >>> 10/26/04 2:29:59 PM >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. Title: Requesting Attributes by Object Class in the Lightweight Directory Access Protocol Author(s): K. Zeilenga Filename: draft-zeilenga-ldap-adlist-09.txt Pages: 6 Date: 2004-10-26 The Lightweight Directory Access Protocol (LDAP) search operation provides mechanisms for clients to request all user application attributes, all operational attributes, and/or attributes selected by their description. This document extends LDAP to support a mechanism that LDAP clients may use to request the return of all attributes belonging to an object class. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-adlist-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldap-adlist-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org . In the body type: "FILE /internet-drafts/draft-zeilenga-ldap-adlist-09.txt". NOTE:The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --=__Part0424378C.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Kurt,
 
This specifies that the class is expanded to all MUST, and MAY = attributes of the class, (either directly or inherited).
 
Does it also include (and exclude) attributes specified in the = DITContentRule for structural classes?
 
Jim

>>> <Internet-Drafts@ietf.org> 10/26/04 = 2:29:59 PM >>>
A New Internet-Draft is available from the = on-line Internet-Drafts directories.


Title: Requesting = Attributes by Object Class in the
Lightweight Directory Access = Protocol
Author(s): K. Zeilenga
Filename: draft-zeilenga-ldap-adlist-= 09.txt
Pages: 6
Date: 2004-10-26

The Lightweight Directory = Access Protocol (LDAP) search operation
provides mechanisms for clients = to request all user application
attributes, all operational attributes, = and/or attributes selected by
their description. This document extends = LDAP to support a mechanism
that LDAP clients may use to request the = return of all attributes
belonging to an object class.

A URL for = this Internet-Draft is:
http://www.ietf.org/internet-drafts/dr= aft-zeilenga-ldap-adlist-09.txt

To remove yourself from = the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the = word unsubscribe in the body of the message.
You can also visit https://www1.i= etf.org/mailman/listinfo/I-D-announce
to change your subscripti= on settings.


Internet-Drafts are also available by anonymous = FTP. Login with the username
"anonymous" and a password of your e-mail = address. After logging in,
type "cd internet-drafts" and then
"get = draft-zeilenga-ldap-adlist-09.txt".

A list of Internet-Drafts = directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-site= s.txt


Internet-Drafts can also be obtained by = e-mail.

Send a message to:
mailserv@ietf.org .
In the body type:
"FILE /internet-draft= s/draft-zeilenga-ldap-adlist-09.txt".

NOTE:The mail server at = ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility. To use this
feature, insert the command "ENCODING = mime" before the "FILE"
command. To decode the response(s), you will = need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant= mail readers
exhibit different behavior, especially when dealing = with
"multipart" MIME messages (i.e. documents which have been = split
up into multiple messages), so check your local documentation = on
how to manipulate these messages.


Below is the data which = will enable a MIME compliant mail reader
implementation to automatically= retrieve the ASCII version of the
Internet-Draft.
--=__Part0424378C.0__=-- --===============0098236887== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0098236887==-- From ldapext-bounces@ietf.org Wed Oct 27 14:29:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29584 for ; Wed, 27 Oct 2004 14:29:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMsVh-0003Rw-VV; Wed, 27 Oct 2004 14:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMsUO-000312-I4 for ldapext@megatron.ietf.org; Wed, 27 Oct 2004 14:25:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29314 for ; Wed, 27 Oct 2004 14:25:38 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMsiI-0003Zv-Q3 for ldapext@ietf.org; Wed, 27 Oct 2004 14:40:03 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9RIPPZv064170; Wed, 27 Oct 2004 18:25:26 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041027111638.03530070@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 27 Oct 2004 11:25:53 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Re: I-D ACTION:draft-zeilenga-ldap-adlist-09.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 10:45 AM 10/27/2004, Jim Sermersheim wrote: >Kurt, > >This specifies that the class is expanded to all MUST, and MAY attributes of the class, (either directly or inherited). For each object class identified in the attributes field, the request is to be treated as if each attribute allowed by that class (by "MUST" or "MAY", directly or by "SUP"erior) [Models] was itself listed. >Does it also include (and exclude) attributes specified in the DITContentRule for structural classes? Attributes allowed or precluded by a DIT Content Rule are not of interest here, only attributes allowed by the listed object class. That is, while a DIT Content Rule may state than an object might belong to a set of classes, hence allowing some set of attributes to be held in the object entry, the DIT Content Rule itself does not specify which attributes are allowed by the object class. > >Jim > >>>> 10/26/04 2:29:59 PM >>> >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > >Title: Requesting Attributes by Object Class in the >Lightweight Directory Access Protocol >Author(s): K. Zeilenga >Filename: draft-zeilenga-ldap-adlist-09.txt >Pages: 6 >Date: 2004-10-26 > >The Lightweight Directory Access Protocol (LDAP) search operation >provides mechanisms for clients to request all user application >attributes, all operational attributes, and/or attributes selected by >their description. This document extends LDAP to support a mechanism >that LDAP clients may use to request the return of all attributes >belonging to an object class. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-adlist-09.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then >"get draft-zeilenga-ldap-adlist-09.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: >mailserv@ietf.org . >In the body type: >"FILE /internet-drafts/draft-zeilenga-ldap-adlist-09.txt". > >NOTE:The mail server at ietf.org can return the document in >MIME-encoded form by using the "mpack" utility. To use this >feature, insert the command "ENCODING mime" before the "FILE" >command. To decode the response(s), you will need "munpack" or >a MIME-compliant mail reader. Different MIME-compliant mail readers >exhibit different behavior, especially when dealing with >"multipart" MIME messages (i.e. documents which have been split >up into multiple messages), so check your local documentation on >how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Oct 27 16:54:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13141 for ; Wed, 27 Oct 2004 16:54:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMuaw-00066e-8m; Wed, 27 Oct 2004 16:40:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMuY2-0004TR-Su for ldapext@megatron.ietf.org; Wed, 27 Oct 2004 16:37:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11034 for ; Wed, 27 Oct 2004 16:37:32 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMulx-0006Z8-IN for ldapext@ietf.org; Wed, 27 Oct 2004 16:51:59 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9RKbMZv065168 for ; Wed, 27 Oct 2004 20:37:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041027130030.0335b778@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 27 Oct 2004 13:37:49 -0700 To: ldapext@ietf.org From: "Kurt D. Zeilenga" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [ldapext] recent draft-zeilenga-ldap-* X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org I recently submitted updates to a number of my individual submissions. All of the submissions were updated to reference the revised LDAP TS I-Ds instead of the existing Proposed Standards (I am optimistic that LDAPBIS will soon advise the revised LDAP TS). The following is a summary of the substantive changes made to each. I have noted the intended category after each I-D. draft-zeilenga-ldap-adlist (Informational) - Updated specification to utilize LDAPBIS ABNF productions. - Noted that object description options are not semantically related to attribute description options. draft-zeilenga-ldap-assert (Standards Track) - Noted that the control is to be processed as an integral part of the operation. - Noted the control is inappropriate for the Start TLS operations. draft-zeilenga-ldap-ext (Informational) - Major rewrite/reorganization of I-D, added sections on + Extending Bind Operation with Controls + Extending StartTLS Operation with Controls + Extending Search Operation with Controls + Extending Update Operations with Controls + Extending Response-less Operations with Controls + General ASN.1 extensibility (replacing SEQUENCE extensions) - and much more draft-zeilenga-ldap-noop (Standards Track) None draft-zeilenga-ldap-readentry (Standards Track) - Added statement regarding proper isolation of operation. - Updated specification to utilize LDAPBIS ABNF productions. - Removed mention of [ProxyAuth] control (seems to have stalled). draft-zeilenga-ldap-t-f (Standards Track) None draft-zeilenga-ldap-turn (Experimental) - flushed out example - dropped the term "turn indicator". draft-zeilenga-ldap-user-schema (Standards Track) - dropped matching rules (most are now published in RFC 3698) - dropped uid (now in LDAPBIS [Schema]) Also, I revised draft-zeilenga-x500-historic (Informational) aimed at moving a number of early X.500 (and related) RFCs to Historic status. Excepting zeilenga-ldap-ext and draft-zeilenga-x500-historic, I believe that these I-Ds are basically ready to be progressed (after fixing a few editorial issues). Please review and comment. (Please start new threads.) Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Oct 27 18:31:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23543 for ; Wed, 27 Oct 2004 18:31:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMwC1-0004N8-Oe; Wed, 27 Oct 2004 18:22:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMw5R-0001Sg-3L for ldapext@megatron.ietf.org; Wed, 27 Oct 2004 18:16:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21792 for ; Wed, 27 Oct 2004 18:16:05 -0400 (EDT) Received: from amos.eb2b.com.au ([210.8.191.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMwJM-0000gV-9u for ldapext@ietf.org; Wed, 27 Oct 2004 18:30:34 -0400 Received: from [192.168.1.155] (210.8.191.250) by amos.eb2b.com.au (7.1.016.1) (authenticated as andrew.sciberras) id 416CAD38000018F8; Thu, 28 Oct 2004 08:25:03 +1000 Message-ID: <41801DF3.9080803@eB2Bcom.com> Date: Thu, 28 Oct 2004 08:15:15 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-au, en-gb, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Password Policy OIDs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew.sciberras@eB2Bcom.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Jim, > The draft probably drifted 'far enough' from both the Novell and > Netscape implementations in the -00 version. The concern is probably how > far has it drifted (or will it drift) from where it was when other > vendors (OpenLDAP, eB2B, and others) started implementing it? > We have implemented the -05 version of this draft. In doing so we did a couple things differently which were conveyed to this list and included within the subsequent drafts. Whilst we're on the discussion of allocating OID's I'd really love to see an OID allocated for the Password Policy Administrative Role. From RFC3672 (Section 2.2): "The Administrative Model defined in [X.501], clause 10 requires that administrative entries contain an administrativeRole attribute to indicate that the associated administrative area is concerned with one or more administrative roles." Cheers, Andrew Sciberras eB2Bcom _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Oct 27 19:26:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27387 for ; Wed, 27 Oct 2004 19:26:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMx9q-0005Ty-Ru; Wed, 27 Oct 2004 19:24:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMx65-0004iG-NA for ldapext@megatron.ietf.org; Wed, 27 Oct 2004 19:20:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26934 for ; Wed, 27 Oct 2004 19:20:50 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMxK2-0001yk-P7 for ldapext@ietf.org; Wed, 27 Oct 2004 19:35:19 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 27 Oct 2004 17:20:21 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Wed, 27 Oct 2004 17:20:04 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Password Policy OIDs Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0716301512==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0716301512== Content-Type: multipart/alternative; boundary="=__PartB0907C34.1__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartB0907C34.1__= Content-Type: text/plain; charset=Windows-1256 Content-Transfer-Encoding: quoted-printable >>> Andrew Sciberras 10/27/04 4:15:15 PM = >>> >Whilst we're on the discussion of allocating OID's I'd really love to=20 >see an OID allocated for the Password Policy Administrative Role. From=20 >RFC3672 (Section 2.2): >"The Administrative Model defined in [X.501], clause 10 requires that >administrative entries contain an administrativeRole attribute to >indicate that the associated administrative area is concerned with >one or more administrative roles." There is a TODO statement in -08 for this (Section 10).=20 =20 FWIW, this is what finally pushed me into raising the thread on the list * = Do I get another OID from the Netscape folks? Do I add the first IANA_ASSIG= NED oid? I'd rather move to all IANA_ASSIGNED oids at the same time I = assign the administrative role OID. =20 We also need to dscribe how these administrative areas work. Can they = overlap? Can they be defined in a way that causes some objects to be = governed by no pwd policy subentry? Can one object be governed by multiple = pwd policy subentries? If so, must each governing subentry list a unique = pwd attribute? =20 Jim =20 --=__PartB0907C34.1__= Content-Type: text/html; charset=Windows-1256 Content-Transfer-Encoding: quoted-printable
>>> Andrew Sciberras <andrew.sciberras@eB2Bcom.com> = 10/27/04 4:15:15 PM >>>
<snip>

>Whilst we're = on the discussion of allocating OID's I'd really love to
>see an = OID allocated for the Password Policy Administrative Role. From
>RFC= 3672 (Section 2.2):
>"The Administrative Model defined in [X.501], = clause 10 requires that
>administrative entries contain an administra= tiveRole attribute to
>indicate that the associated administrative = area is concerned with
>one or more administrative roles."
There is a TODO statement in -08 for this (Section 10).
 
FWIW, this is what finally pushed me into raising the thread on the = list =97 Do I get another OID from the Netscape folks? Do I add the first = IANA_ASSIGNED oid? I'd rather move to all IANA_ASSIGNED oids at the same = time I assign the administrative role OID.
 
We also need to dscribe how these administrative areas work. Can they = overlap? Can they be defined in a way that causes some objects to be = governed by no pwd policy subentry? Can one object be governed by multiple = pwd policy subentries? If so, must each governing subentry list a unique = pwd attribute?
 
Jim
 
--=__PartB0907C34.1__=-- --===============0716301512== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0716301512==-- From ldapext-bounces@ietf.org Wed Oct 27 19:41:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28445 for ; Wed, 27 Oct 2004 19:41:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMxNi-0007Uh-Rf; Wed, 27 Oct 2004 19:39:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMxKH-00074l-LH for ldapext@megatron.ietf.org; Wed, 27 Oct 2004 19:35:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28145 for ; Wed, 27 Oct 2004 19:35:30 -0400 (EDT) Received: from amos.eb2b.com.au ([210.8.191.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMxYE-0002KK-17 for ldapext@ietf.org; Wed, 27 Oct 2004 19:49:59 -0400 Received: from [192.168.1.155] (210.8.191.250) by amos.eb2b.com.au (7.1.016.1) (authenticated as andrew.sciberras) id 416CAD3800001929; Thu, 28 Oct 2004 09:44:28 +1000 Message-ID: <41803090.2010202@eB2Bcom.com> Date: Thu, 28 Oct 2004 09:34:40 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-au, en-gb, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Password Policy OIDs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew.sciberras@eB2Bcom.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: >>>> Andrew Sciberras 10/27/04 >>>> 4:15:15 PM >>> > There is a TODO statement in -08 for this (Section 10). Sorry, I guess I should open my eyes! > > FWIW, this is what finally pushed me into raising the thread on the > list * Do I get another OID from the Netscape folks? Do I add the > first IANA_ASSIGNED oid? I'd rather move to all IANA_ASSIGNED oids at > the same time I assign the administrative role OID. > Here's what we did: * Defined our own temporary internal OID for the admin role > We also need to dscribe how these administrative areas work. Can they > overlap? * No overlapping - i.e Specific Administrative Area We made this decision based on the comment: "It SHOULD be possible to overwrite the password policy for one user by defining a new policy in a subentry of the user entry." >Can they be defined in a way that causes some objects to be > governed by no pwd policy subentry? * Yes, we can do this through the subtreeSpecification attribute > Can one object be governed by multiple pwd policy subentries? > If so, must each governing subentry list a unique pwd attribute? Not sure what your asking here... Is an object and entry or a password attribute? Many subentries can apply to a single entry. If there are multiple password policy subentries under the one administrative point then I think that they should all be distinctly different. Essentially, no two policies should be able to be applied to the attribute within an entry. This may be hard to manage, so it probably would be easier to simply say that "each governing subentry list a unique pwd attribute". > > Jim > Andrew Sciberras. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Oct 27 19:47:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28812 for ; Wed, 27 Oct 2004 19:47:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMxU7-0008Un-9i; Wed, 27 Oct 2004 19:45:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMxPH-0007i8-Bs for ldapext@megatron.ietf.org; Wed, 27 Oct 2004 19:40:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28393 for ; Wed, 27 Oct 2004 19:40:39 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMxdE-0002R5-Po for ldapext@ietf.org; Wed, 27 Oct 2004 19:55:09 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i9RNeZZv066285; Wed, 27 Oct 2004 23:40:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041027162651.03258e30@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 27 Oct 2004 16:41:02 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: OIDs (Was: [ldapext] Password Policy OIDs) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: andrew.sciberras@eB2Bcom.com, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable At 04:20 PM 10/27/2004, Jim Sermersheim wrote: >FWIW, this is what finally pushed me into raising the thread on the list = =97 Do I get another OID from the Netscape folks? Do I add the first= IANA_ASSIGNED oid? I'd rather move to all IANA_ASSIGNED oids at the same= time I assign the administrative role OID. I suggest you use a marker in the I-D, IANA-ASSIGNED-OID, for the one "directory" OID to be assigned by IANA. The RFC Editor will replace this with the assigned "directory" OID just prior to publication. Or you can ask IANA an experimental OID to the I-D and use that while the I-D is a "work in progress". The RFC Editor will replace this OID just prior to publication with an IANA assigned directory OID. In either case, you'll need an IANA consideration section requesting an OID be assigned to the RFC (as well as detailing all uses of that OID), as well as note to the RFC Editor to do the appropriate edits (especially in the latter case). I generally recommend the former approach. You should generally avoid use of private OIDs in IETF standards. See BCP 64 (RFC 3383) for guidance. =20 >=20 >We also need to dscribe how these administrative areas work. Can they= overlap? Can they be defined in a way that causes some objects to be= governed by no pwd policy subentry? Can one object be governed by multiple= pwd policy subentries? If so, must each governing subentry list a unique= pwd attribute? >=20 >Jim >=20 >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Oct 27 20:07:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29902 for ; Wed, 27 Oct 2004 20:07:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMxmW-00034B-Pz; Wed, 27 Oct 2004 20:04:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMxg6-0001fT-LO for ldapext@megatron.ietf.org; Wed, 27 Oct 2004 19:58:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29260 for ; Wed, 27 Oct 2004 19:58:05 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMxu4-0002jh-HQ for ldapext@ietf.org; Wed, 27 Oct 2004 20:12:32 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 27 Oct 2004 17:57:35 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Wed, 27 Oct 2004 17:57:14 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Password Policy OIDs Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit >>> Andrew Sciberras 10/27/04 5:34:40 PM >>> >>We also need to dscribe how these administrative areas work. Can they >> overlap? >* No overlapping - i.e Specific Administrative Area >We made this decision based on the comment: >"It SHOULD be possible to overwrite the password policy for one >user by defining a new policy in a subentry of the user entry." Right, but someone may want to define one policy for person objects, and another policy for widget objects, where persons and widgets fall under the same hierarchy. >> Can one object be governed by multiple pwd policy subentries? >> If so, must each governing subentry list a unique pwd attribute? >Not sure what your asking here... Is an object and entry or a password >attribute? >Many subentries can apply to a single entry. If there are multiple >password policy subentries under the one administrative point then I >think that they should all be distinctly different. Essentially, no two >policies should be able to be applied to the attribute within an entry. >This may be hard to manage, so it probably would be easier to simply say >that "each governing subentry list a unique pwd attribute". I'm just saying, we need to decide and specify these things. AFAIK, administrative policy specifications are responsible to make statements as to whether policies may be combined, and how (...for each specific aspect of administrative authority, a definition is required of the method of combination of administrative information when it is possible for entries to be included in more than one subtree or subtree refinement...). For example, while we _may_ want to allow multiple password policy subentries to apply to a single object (each associated with a different attribute), other administrative areas do not allow multiple subentries to apply to a single object (like subschema). The limits and allowances for these kinds of things are supposed to be called out in the specification, but the pwd policy specification makes no (or very few, vague) statements along these lines. Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Oct 27 20:13:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00207 for ; Wed, 27 Oct 2004 20:13:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMxrN-0003mF-KP; Wed, 27 Oct 2004 20:09:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMxqd-0003cI-4b for ldapext@megatron.ietf.org; Wed, 27 Oct 2004 20:08:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29986 for ; Wed, 27 Oct 2004 20:08:57 -0400 (EDT) Received: from amos.eb2b.com.au ([210.8.191.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMy4Z-0002wt-SV for ldapext@ietf.org; Wed, 27 Oct 2004 20:23:25 -0400 Received: from [192.168.1.155] (210.8.191.250) by amos.eb2b.com.au (7.1.016.1) (authenticated as andrew.sciberras) id 416CAD380000194B; Thu, 28 Oct 2004 10:17:41 +1000 Message-ID: <41803859.9030503@eB2Bcom.com> Date: Thu, 28 Oct 2004 10:07:53 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-au, en-gb, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Password Policy OIDs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew.sciberras@eB2Bcom.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: > Right, but someone may want to define one policy for person objects, > and another policy for widget objects, where persons and widgets fall > under the same hierarchy. > I'm not sure to what extent the SubtreeSpecification attribute is supported within LDAP directories, but you can certainly achieve your above statement by using the substreeSpecification att. This is due to the 'Refinement' choice within the SubtreeSpecification structure that allows you to filter which entries the policy applies to based on their object class. Andrew _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Oct 27 20:35:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01574 for ; Wed, 27 Oct 2004 20:35:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMyEc-0007JM-C5; Wed, 27 Oct 2004 20:33:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMyDh-0006xK-Bh for ldapext@megatron.ietf.org; Wed, 27 Oct 2004 20:32:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01354 for ; Wed, 27 Oct 2004 20:32:47 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMyRe-0003Li-Hd for ldapext@ietf.org; Wed, 27 Oct 2004 20:47:16 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 27 Oct 2004 18:32:17 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Wed, 27 Oct 2004 18:31:56 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Password Policy OIDs Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0638393545==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0638393545== Content-Type: multipart/alternative; boundary="=__Part7858B4EC.1__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part7858B4EC.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Right, I know the mechanism used for this, but... I was under the impression that a specification of an administrative policy is responsible to make statements as to whether or not such things are allowed. And if allowed, what restrictions exist (in pwd policy's case, one restriction is to not allow a single object to be governed by two pwd policy subentries each specifying the same pwd attribute). For example, the specification for the subschema administrative area makes some statement (though I can't find it now) which restricts an object to only being governed by a single subschema subentry. Jim >>> Andrew Sciberras 10/27/04 6:07:53 PM >>> Jim Sermersheim wrote: > Right, but someone may want to define one policy for person objects, > and another policy for widget objects, where persons and widgets fall > under the same hierarchy. > I'm not sure to what extent the SubtreeSpecification attribute is supported within LDAP directories, but you can certainly achieve your above statement by using the substreeSpecification att. This is due to the 'Refinement' choice within the SubtreeSpecification structure that allows you to filter which entries the policy applies to based on their object class. Andrew --=__Part7858B4EC.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Right, I know the mechanism used for this, but...
 
I was under the impression that a specification of an administrative = policy is responsible to make statements as to whether or not such things = are allowed. And if allowed, what restrictions exist (in pwd policy's = case, one restriction is to not allow a single object to be governed by = two pwd policy subentries each specifying the same pwd attribute).
 
For example, the specification for the subschema administrative area = makes some statement (though I can't find it now) which restricts an = object to only being governed by a single subschema subentry.
 
Jim

>>> Andrew Sciberras <andrew.sciberras@eB2Bcom.com>= 10/27/04 6:07:53 PM >>>
Jim Sermersheim wrote:

> = Right, but someone may want to define one policy for person objects,
>= ; and another policy for widget objects, where persons and widgets = fall
> under the same hierarchy.
>

I'm not sure to = what extent the SubtreeSpecification attribute is
supported within = LDAP directories, but you can certainly achieve your
above statement = by using the substreeSpecification att. This is due to
the 'Refinement'= choice within the SubtreeSpecification structure that
allows you to = filter which entries the policy applies to based on their
object = class.

Andrew
--=__Part7858B4EC.1__=-- --===============0638393545== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0638393545==-- From ldapext-bounces@ietf.org Thu Oct 28 08:49:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08338 for ; Thu, 28 Oct 2004 08:49:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN9d3-0003Ym-QM; Thu, 28 Oct 2004 08:43:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN9c5-0003Is-5x for ldapext@megatron.ietf.org; Thu, 28 Oct 2004 08:42:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07972 for ; Thu, 28 Oct 2004 08:42:44 -0400 (EDT) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN9q9-0008Q0-Gb for ldapext@ietf.org; Thu, 28 Oct 2004 08:57:18 -0400 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 28 Oct 2004 13:41:48 +0100 Message-ID: <4180E902.60803@isode.com> Date: Thu, 28 Oct 2004 13:41:38 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Subject: Re: [ldapext] Splitting Password Policy References: <6.1.2.0.0.20041026091821.02e198d0@127.0.0.1> In-Reply-To: <6.1.2.0.0.20041026091821.02e198d0@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: Duane Buss , ldapext@ietf.org, Hal Henderson , Tammy Green , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >Just a thought, but it might also be useful to split the >protocol elements from the schema elements. The protocol >controls could be genericized to support expiration of >other kinds of credentials. > I agree. And the password policy control can be used with other password policies (e.g. NIS schema). So yes, I am in favor of splitting the control and other protocol bits into a separate document. > >At 09:00 AM 10/26/2004, Jim Sermersheim wrote: > > >>All, >> >>Speaking on behalf of some people on the CC list, it is seen as desirable to place password update policy in one specification, and place password use policy in another specification. >> >>This started as an act of associating password use policy (such as intruder detection policy) with login policy (such as allowable login times, addresses, etc). >> >>It then diverged from that and ended up being described as: Password policy is policy that applies only to simple bind passwords. Login policy involves policy that can be applied to *any* kind of credentials. >> >>My argument was that policy like password expiration (while enforced at authN time) is intimately tied to password updates. Thus, if we were to split this into two I-Ds, there would be some amount of cross referencing, and cross requirements (password expiration would require actions during password update). >> >>I know some people in the community have asked for more "login policy" type things to be added to the I-D, and we've pushed against adding those. >> >>What are other's feelings in this area? (Tammy, Duane, Hal, feel free to clarify these positions). >> >> >> _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Oct 28 19:45:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15903 for ; Thu, 28 Oct 2004 19:45:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNHtt-0002qG-Du; Thu, 28 Oct 2004 17:33:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNFoS-0004Wx-Lq for ldapext@megatron.ietf.org; Thu, 28 Oct 2004 15:19:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20834 for ; Thu, 28 Oct 2004 15:19:55 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNG2a-0005hV-Ft for ldapext@ietf.org; Thu, 28 Oct 2004 15:34:33 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 28 Oct 2004 13:19:22 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Thu, 28 Oct 2004 13:18:55 -0600 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] Splitting Password Policy Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: Hal Henderson , Duane Buss , ldapext@ietf.org, Tammy Green X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0461909502==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0461909502== Content-Type: multipart/alternative; boundary="=__PartE1C12C0F.0__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartE1C12C0F.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I think I can do that. For purposes of reuse, it will require that the protocol specification only give abstract descriptions as to the reasons why certain errors and warnings are to be returned, and the pwd policy doc (containing the data model) will prescribe specific behavior regarding the state data. Jim >>> Alexey Melnikov 10/28/04 6:41:38 AM >>> Kurt D. Zeilenga wrote: >Just a thought, but it might also be useful to split the >protocol elements from the schema elements. The protocol >controls could be genericized to support expiration of >other kinds of credentials. > I agree. And the password policy control can be used with other password policies (e.g. NIS schema). So yes, I am in favor of splitting the control and other protocol bits into a separate document. > >At 09:00 AM 10/26/2004, Jim Sermersheim wrote: > > >>All, >> >>Speaking on behalf of some people on the CC list, it is seen as desirable to place password update policy in one specification, and place password use policy in another specification. >> >>This started as an act of associating password use policy (such as intruder detection policy) with login policy (such as allowable login times, addresses, etc). >> >>It then diverged from that and ended up being described as: Password policy is policy that applies only to simple bind passwords. Login policy involves policy that can be applied to *any* kind of credentials. >> >>My argument was that policy like password expiration (while enforced at authN time) is intimately tied to password updates. Thus, if we were to split this into two I-Ds, there would be some amount of cross referencing, and cross requirements (password expiration would require actions during password update). >> >>I know some people in the community have asked for more "login policy" type things to be added to the I-D, and we've pushed against adding those. >> >>What are other's feelings in this area? (Tammy, Duane, Hal, feel free to clarify these positions). >> >> >> _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__PartE1C12C0F.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think I can do that.
 
For purposes of reuse, it will require that the protocol specification= only give abstract descriptions as to the reasons why certain errors and = warnings are to be returned, and the pwd policy doc (containing the data = model) will prescribe specific behavior regarding the state data.
 
Jim

>>> Alexey Melnikov <Alexey.Melnikov@isode.com&= gt; 10/28/04 6:41:38 AM >>>
Kurt D. Zeilenga wrote:

>= Just a thought, but it might also be useful to split the
>protocol = elements from the schema elements. The protocol
>controls could be = genericized to support expiration of
>other kinds of credentials.
= >
I agree.
And the password policy control can be used with other = password policies
(e.g. NIS schema).
So yes, I am in favor of = splitting the control and other protocol bits
into a separate = document.

>
>At 09:00 AM 10/26/2004, Jim Sermersheim = wrote:
>
>
>>All,
>>
>>Speaking on = behalf of some people on the CC list, it is seen as desirable to place = password update policy in one specification, and place password use policy = in another specification.
>>
>>This started as an act of = associating password use policy (such as intruder detection policy) with = login policy (such as allowable login times, addresses, etc).
>>>>It then diverged from that and ended up being described as: = Password policy is policy that applies only to simple bind passwords. = Login policy involves policy that can be applied to *any* kind of = credentials.
>>
>>My argument was that policy like = password expiration (while enforced at authN time) is intimately tied to = password updates. Thus, if we were to split this into two I-Ds, there = would be some amount of cross referencing, and cross requirements = (password expiration would require actions during password update).
>= >
>>I know some people in the community have asked for more = "login policy" type things to be added to the I-D, and we've pushed = against adding those.
>>
>>What are other's feelings in = this area? (Tammy, Duane, Hal, feel free to clarify these positions).
&g= t;>
>>
>>

____________________________________= ___________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext =
--=__PartE1C12C0F.0__=-- --===============0461909502== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0461909502==-- From ldapext-bounces@ietf.org Thu Oct 28 23:12:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01112 for ; Thu, 28 Oct 2004 23:12:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNMeK-0002jY-SI; Thu, 28 Oct 2004 22:37:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNKSh-0004CC-DW for ldapext@megatron.ietf.org; Thu, 28 Oct 2004 20:17:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25236 for ; Thu, 28 Oct 2004 20:17:45 -0400 (EDT) Received: from [210.8.119.70] (helo=micah.software-aus.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNKgp-0008A4-QU for ldapext@ietf.org; Thu, 28 Oct 2004 20:32:25 -0400 Received: from eb2bcom.com (192.168.1.166) by micah.software-aus.com.au (7.1.016.1) (authenticated as steven.legg) id 416CB17000001887; Fri, 29 Oct 2004 10:22:42 +1000 Message-ID: <41818C0A.1060701@eb2bcom.com> Date: Fri, 29 Oct 2004 10:17:14 +1000 From: Steven Legg User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Password Policy OIDs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim, Jim Sermersheim wrote: > Right, I know the mechanism used for this, but... > > I was under the impression that a specification of an administrative > policy is responsible to make statements as to whether or not such > things are allowed. And if allowed, what restrictions exist (in pwd > policy's case, one restriction is to not allow a single object to be > governed by two pwd policy subentries each specifying the same pwd > attribute). > > For example, the specification for the subschema administrative area > makes some statement (though I can't find it now) which restricts an > object to only being governed by a single subschema subentry. FYI, it comes about as a consequence of there being no such thing as a subschema inner administrative area, and the requirement that a subschema administrative point have no more than one subschema subentry. Regards, Steven > > Jim > > >>> Andrew Sciberras 10/27/04 6:07:53 PM >>> > Jim Sermersheim wrote: > > > Right, but someone may want to define one policy for person objects, > > and another policy for widget objects, where persons and widgets fall > > under the same hierarchy. > > > > I'm not sure to what extent the SubtreeSpecification attribute is > supported within LDAP directories, but you can certainly achieve your > above statement by using the substreeSpecification att. This is due to > the 'Refinement' choice within the SubtreeSpecification structure that > allows you to filter which entries the policy applies to based on their > object class. > > Andrew > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Oct 28 23:24:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02373 for ; Thu, 28 Oct 2004 23:24:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNMsC-0002cq-T5; Thu, 28 Oct 2004 22:52:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNLzM-0007a9-SH for ldapext@megatron.ietf.org; Thu, 28 Oct 2004 21:55:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17794 for ; Thu, 28 Oct 2004 21:55:35 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNMDY-0006qI-80 for ldapext@ietf.org; Thu, 28 Oct 2004 22:10:16 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 28 Oct 2004 19:55:05 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Thu, 28 Oct 2004 19:54:40 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Password Policy OIDs Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1440075572==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============1440075572== Content-Type: multipart/alternative; boundary="=__PartFADA37F0.1__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartFADA37F0.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Thanks for the clarification. So I think we want to specify these things for the pwd policy (is there such a thing pwdPolicy inner administrative area? Can a pwdPolicy administrative point have multiple subentries?) I think I'm hearing Yes, and Maybe Not (respectively). To allow multiple subentries, some requirement must be given such that no two subentries govern the same pwd attribute. Also, the state information doen't currently allow for multiple policies (Ludo and I worked on that solution once, and gave up). Jim >>> Steven Legg 10/28/04 6:17:14 PM >>> Jim, Jim Sermersheim wrote: > Right, I know the mechanism used for this, but... > > I was under the impression that a specification of an administrative > policy is responsible to make statements as to whether or not such > things are allowed. And if allowed, what restrictions exist (in pwd > policy's case, one restriction is to not allow a single object to be > governed by two pwd policy subentries each specifying the same pwd > attribute). > > For example, the specification for the subschema administrative area > makes some statement (though I can't find it now) which restricts an > object to only being governed by a single subschema subentry. FYI, it comes about as a consequence of there being no such thing as a subschema inner administrative area, and the requirement that a subschema administrative point have no more than one subschema subentry. Regards, Steven > > Jim > > >>> Andrew Sciberras < andrew.sciberras@eB2Bcom.com > 10/27/04 6:07:53 PM >>> > Jim Sermersheim wrote: > > > Right, but someone may want to define one policy for person objects, > > and another policy for widget objects, where persons and widgets fall > > under the same hierarchy. > > > > I'm not sure to what extent the SubtreeSpecification attribute is > supported within LDAP directories, but you can certainly achieve your > above statement by using the substreeSpecification att. This is due to > the 'Refinement' choice within the SubtreeSpecification structure that > allows you to filter which entries the policy applies to based on their > object class. > > Andrew > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext --=__PartFADA37F0.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the clarification.
 
So I think we want to specify these things for the pwd policy (is = there such a thing pwdPolicy inner administrative area? Can a pwdPolicy = administrative point have multiple subentries?)
 
I think I'm hearing Yes, and Maybe Not (respectively).
 
To allow multiple subentries, some requirement must be given such = that no two subentries govern the same pwd attribute. Also, the state = information doen't currently allow for multiple policies (Ludo and I = worked on that solution once, and gave up).
 
Jim

>>> Steven Legg <steven.legg@eb2bcom.com> = 10/28/04 6:17:14 PM >>>

Jim,

Jim Sermersheim = wrote:
> Right, I know the mechanism used for this, but...
> =
> I was under the impression that a specification of an administrati= ve
> policy is responsible to make statements as to whether or not = such
> things are allowed. And if allowed, what restrictions exist = (in pwd
> policy's case, one restriction is to not allow a single = object to be
> governed by two pwd policy subentries each specifying= the same pwd
> attribute).
>
> For example, the = specification for the subschema administrative area
> makes some = statement (though I can't find it now) which restricts an
> object = to only being governed by a single subschema subentry.

FYI, it = comes about as a consequence of there being no such thing as a subschemainner administrative area, and the requirement that a subschema administra= tive
point have no more than one subschema subentry.

Regards,
= Steven

>
> Jim
>
> >>> Andrew = Sciberras < andrew.sc= iberras@eB2Bcom.com > 10/27/04 6:07:53 PM >>>
> = Jim Sermersheim wrote:
>
> > Right, but someone may want = to define one policy for person objects,
> > and another policy = for widget objects, where persons and widgets fall
> > under the = same hierarchy.
> >
>
> I'm not sure to what extent = the SubtreeSpecification attribute is
> supported within LDAP = directories, but you can certainly achieve your
> above statement by = using the substreeSpecification att. This is due to
> the 'Refinement= ' choice within the SubtreeSpecification structure that
> allows you = to filter which entries the policy applies to based on their
> = object class.
>
> Andrew
>
>
> -----------= -------------------------------------------------------------
> =
> _______________________________________________
> Ldapext = mailing list
> Ldapext@ietf.or= g
> https://www1.ietf.org/mailman/listinfo/ldapext
--=__PartFADA37F0.1__=-- --===============1440075572== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============1440075572==-- From ldapext-bounces@ietf.org Thu Oct 28 23:25:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02440 for ; Thu, 28 Oct 2004 23:25:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNMtl-0004qJ-NE; Thu, 28 Oct 2004 22:53:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNM6G-0002fG-8f for ldapext@megatron.ietf.org; Thu, 28 Oct 2004 22:02:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20171 for ; Thu, 28 Oct 2004 22:02:42 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNMKR-0007WZ-5L for ldapext@ietf.org; Thu, 28 Oct 2004 22:17:23 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 28 Oct 2004 20:02:12 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Thu, 28 Oct 2004 20:01:53 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Password Policy OIDs Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1165465482==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============1165465482== Content-Type: multipart/alternative; boundary="=__Part8DAD4081.1__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part8DAD4081.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Something I said below is wrong: Ludo and I worked on that solution and it's still part of the draft (Section 5.3.1 Password Policy State Attribute Option). So there is a provision to place multiple pwd policy subentries under a single AP, we just need to specify that they can't govern the same pwd attribute. I think I'll take a break... Jim >>> Jim Sermersheim >>> Thanks for the clarification. So I think we want to specify these things for the pwd policy (is there such a thing pwdPolicy inner administrative area? Can a pwdPolicy administrative point have multiple subentries?) I think I'm hearing Yes, and Maybe Not (respectively). To allow multiple subentries, some requirement must be given such that no two subentries govern the same pwd attribute. Also, the state information doen't currently allow for multiple policies (Ludo and I worked on that solution once, and gave up). Jim >>> Steven Legg 10/28/04 6:17:14 PM >>> Jim, Jim Sermersheim wrote: > Right, I know the mechanism used for this, but... > > I was under the impression that a specification of an administrative > policy is responsible to make statements as to whether or not such > things are allowed. And if allowed, what restrictions exist (in pwd > policy's case, one restriction is to not allow a single object to be > governed by two pwd policy subentries each specifying the same pwd > attribute). > > For example, the specification for the subschema administrative area > makes some statement (though I can't find it now) which restricts an > object to only being governed by a single subschema subentry. FYI, it comes about as a consequence of there being no such thing as a subschema inner administrative area, and the requirement that a subschema administrative point have no more than one subschema subentry. Regards, Steven > > Jim > > >>> Andrew Sciberras < andrew.sciberras@eB2Bcom.com > 10/27/04 6:07:53 PM >>> > Jim Sermersheim wrote: > > > Right, but someone may want to define one policy for person objects, > > and another policy for widget objects, where persons and widgets fall > > under the same hierarchy. > > > > I'm not sure to what extent the SubtreeSpecification attribute is > supported within LDAP directories, but you can certainly achieve your > above statement by using the substreeSpecification att. This is due to > the 'Refinement' choice within the SubtreeSpecification structure that > allows you to filter which entries the policy applies to based on their > object class. > > Andrew > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext --=__Part8DAD4081.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Something I said below is wrong:
 
Ludo and I worked on that solution and it's still part of the draft = (Section 5.= 3.1 Password Policy State Attribute Option).
 
So there is a provision to place multiple pwd policy subentries under = a single AP, we just need to specify that they can't govern the same pwd = attribute.
 
I think I'll take a break...
 
Jim
 
>>> Jim Sermersheim >>>
Thanks for the clarification.
 
So I think we want to specify these things for the pwd policy (is = there such a thing pwdPolicy inner administrative area? Can a pwdPolicy = administrative point have multiple subentries?)
 
I think I'm hearing Yes, and Maybe Not (respectively).
 
To allow multiple subentries, some requirement must be given such = that no two subentries govern the same pwd attribute. Also, the state = information doen't currently allow for multiple policies (Ludo and I = worked on that solution once, and gave up).
 
Jim

>>> Steven Legg <steven.legg@eb2bcom.com> = 10/28/04 6:17:14 PM >>>

Jim,

Jim Sermersheim = wrote:
> Right, I know the mechanism used for this, but...
> =
> I was under the impression that a specification of an administrati= ve
> policy is responsible to make statements as to whether or not = such
> things are allowed. And if allowed, what restrictions exist = (in pwd
> policy's case, one restriction is to not allow a single = object to be
> governed by two pwd policy subentries each specifying= the same pwd
> attribute).
>
> For example, the = specification for the subschema administrative area
> makes some = statement (though I can't find it now) which restricts an
> object = to only being governed by a single subschema subentry.

FYI, it = comes about as a consequence of there being no such thing as a subschemainner administrative area, and the requirement that a subschema administra= tive
point have no more than one subschema subentry.

Regards,
= Steven

>
> Jim
>
> >>> Andrew = Sciberras < andrew.sc= iberras@eB2Bcom.com > 10/27/04 6:07:53 PM >>>
> = Jim Sermersheim wrote:
>
> > Right, but someone may want = to define one policy for person objects,
> > and another policy = for widget objects, where persons and widgets fall
> > under the = same hierarchy.
> >
>
> I'm not sure to what extent = the SubtreeSpecification attribute is
> supported within LDAP = directories, but you can certainly achieve your
> above statement by = using the substreeSpecification att. This is due to
> the 'Refinement= ' choice within the SubtreeSpecification structure that
> allows you = to filter which entries the policy applies to based on their
> = object class.
>
> Andrew
>
>
> -----------= -------------------------------------------------------------
> =
> _______________________________________________
> Ldapext = mailing list
> Ldapext@ietf.or= g
> https://www1.ietf.org/mailman/listinfo/ldapext
--=__Part8DAD4081.1__=-- --===============1165465482== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============1165465482==-- From ldapext-bounces@ietf.org Fri Oct 29 14:24:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21409 for ; Fri, 29 Oct 2004 14:24:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNbHv-0007KW-Vj; Fri, 29 Oct 2004 14:15:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNb9m-0003g2-3g for ldapext@megatron.ietf.org; Fri, 29 Oct 2004 14:07:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20537 for ; Fri, 29 Oct 2004 14:07:20 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNbO5-0004uw-7y for ldapext@ietf.org; Fri, 29 Oct 2004 14:22:10 -0400 Received: from phys-aus08-1 ([129.153.131.88]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9TI7JNH005416 for ; Fri, 29 Oct 2004 12:07:19 -0600 (MDT) Received: from conversion-daemon.aus08-mail1.central.sun.com by aus08-mail1.central.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I6C00M01XME55@aus08-mail1.central.sun.com> (original mail from Andrew.Coulbeck@Sun.COM) for ldapext@ietf.org; Fri, 29 Oct 2004 13:07:19 -0500 (CDT) Received: from sun.com (ibis.Central.Sun.COM [129.153.130.74]) by aus08-mail1.central.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0I6C0096TYC65W@aus08-mail1.central.sun.com> for ldapext@ietf.org; Fri, 29 Oct 2004 13:07:19 -0500 (CDT) Date: Fri, 29 Oct 2004 13:07:49 -0500 From: Andy Coulbeck To: ldapext@ietf.org Message-id: <418286F5.90500@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030922 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7BIT Subject: [ldapext] password policy expiration check X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7BIT I am looking at draft-behera-ldap-password-policy-08.txt and I do not understand section 7.3 Password Expiration Check. It seems to say that passwords do not expire unless pwdExpireWarning is zero. Surely it should say instead that passwords do not expire unless pwdMaxAge is non-zero. 7.3 Password Expiration Check A status of true is returned indicating that the password has expired if the value of the pwdExpireWarning attribute is 0, and the current time minus the value of pwdChangedTime is greater than the value of the pwdMaxAge. Otherwise, a status of false is returned. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Oct 29 15:46:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29707 for ; Fri, 29 Oct 2004 15:46:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNcM2-0000II-Mf; Fri, 29 Oct 2004 15:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNcFY-0007tI-PJ for ldapext@megatron.ietf.org; Fri, 29 Oct 2004 15:17:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26744 for ; Fri, 29 Oct 2004 15:17:22 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNcTt-0006QC-F1 for ldapext@ietf.org; Fri, 29 Oct 2004 15:32:13 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 29 Oct 2004 13:16:53 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Fri, 29 Oct 2004 13:16:32 -0600 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] password policy expiration check Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0317831106==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0317831106== Content-Type: multipart/alternative; boundary="=__Part3C1CF200.0__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part3C1CF200.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Will fix this in -09 >>> Andy Coulbeck 10/29/04 12:07:49 PM >>> I am looking at draft-behera-ldap-password-policy-08.txt and I do not understand section 7.3 Password Expiration Check. It seems to say that passwords do not expire unless pwdExpireWarning is zero. Surely it should say instead that passwords do not expire unless pwdMaxAge is non-zero. 7.3 Password Expiration Check A status of true is returned indicating that the password has expired if the value of the pwdExpireWarning attribute is 0, and the current time minus the value of pwdChangedTime is greater than the value of the pwdMaxAge. Otherwise, a status of false is returned. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__Part3C1CF200.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Will fix this in = -09

>>> Andy Coulbeck <Andrew.Coulbeck@Sun.COM> = 10/29/04 12:07:49 PM >>>
I am looking at draft-behera-ldap-pass= word-policy-08.txt and I do not
understand section 7.3 Password = Expiration Check. It seems to say
that passwords do not expire unless = pwdExpireWarning is zero. Surely
it should say instead that passwords = do not expire unless pwdMaxAge
is non-zero.

7.3 Password = Expiration Check

A status of true is returned indicating that the = password has expired
if the value of the pwdExpireWarning attribute is = 0, and the current
time minus the value of pwdChangedTime is greater = than the value of
the pwdMaxAge.

Otherwise, a status of false is = returned.


_______________________________________________
Lda= pext mailing list
Ldapext@ietf.or= g
https://www1.ietf.org/mailman/listinfo/ldapext
--=__Part3C1CF200.0__=-- --===============0317831106== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0317831106==--