From ldapext-admin@ietf.org  Sun Nov  2 18:38:33 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29704
	for <ldapext-archive@lists.ietf.org>; Sun, 2 Nov 2003 18:38:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGRnF-0001gF-O7; Sun, 02 Nov 2003 18:38:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGRn2-0001ez-4G
	for ldapext@optimus.ietf.org; Sun, 02 Nov 2003 18:37:48 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29666
	for <ldapext@ietf.org>; Sun, 2 Nov 2003 18:37:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGRmz-0004C5-00
	for ldapext@ietf.org; Sun, 02 Nov 2003 18:37:45 -0500
Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGRmx-0004Bo-00
	for ldapext@ietf.org; Sun, 02 Nov 2003 18:37:44 -0500
Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16)
	id <B000196358>; Mon, 03 Nov 2003 10:30:09 +1100
Received: (qmail 6701 invoked from network); 2 Nov 2003 23:37:12 -0000
Received: from unknown (HELO shylock) (10.32.24.166)
  by nexus.adacel.com with SMTP; 2 Nov 2003 23:37:12 -0000
Reply-To: <andrews@adacel.com.au>
From: "Andrew Sciberras" <andrews@adacel.com.au>
To: "Ldapext \(E-mail\)" <ldapext@ietf.org>
Subject: RE: [ldapext] draft-ietf-boreham-numsubordinates-01.txt
Date: Mon, 3 Nov 2003 10:37:11 +1100
Message-ID: <04bf01c3a19a$3dcff420$a618200a@mtwav.adacel.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <OF72A40A60.D5A5C2D5-ON86256DD0.00449117-86256DD0.0046727C@us.ibm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

>I feel that numsubordinates should return 0 when hassubordinates would
>return FALSE.  Since hassubordinates can include subentries,
>numsubordinates should also.
>
>John  McMeeking
>


Hi,

I think that subentries should not be included in the numSubordinates count.

If a use-case for the numSubordinates is to aid a GUI in deciding (for
browsing purposes) if an entry is a leaf, then returning 0 (zero) for an
entry with one or more subentry's and zero subordinate entries is
acceptable. This is because, under your general browsing and searching type
operations, subentries are not considered.
If the GUI was being used for Administrative purposes, where subentries may
wish to be explored, then simply checking if the entry is an administrative
point should accomplish this.


Another possible use-case for the numSubordinates attribute, which has been
expressed on this list, is for making decisions as to whether the entry is a
leaf for deletion purposes. Ludovic correctly pointed out that having
numSubordinates == 0 and getting a NON_LEAF error when deleting would be
confusing.
I don't believe a use-case of numSubordinates should be to identify if an
entry is a leaf for deletion purposes. Aside from ignoring subentries, the
scenario of numSubordinates == 0 and a NON_LEAF error will occur when the
user does not have sufficient permissions for the subordinate entries to be
included within the numSubordinates count.

On the topic of access control... The draft states:
'Servers MUST ensure that the value returned in the numSubordinates
attribute to clients is consistent with the view that client has of other
server contents.'
It has been established that this means that Access Controls should be taken
into consideration when returning the numSubordinates value.
I think the draft should be a little more specific though. Depending on what
the intended use-case of numSubordinates is, a statement should exist
regarding which permissions should be assessed when returning a
numSubordinates value.
E.g..
* Is the decision based on modify or read permissions?
* What happens if the entry's DN can be returned in a search, but the user
is not allowed to browse its contents?
* Which Access Control specification are we referring to? (BAC as defined in
X501, or the old draft-ietf-ldapext-acl-model-xx.txt)


Not including subentries within the numSubordinates count does introduce an
inconsistency between the numSubordinates and hasSubordinates attributes.
Is it the intention of this specification to maintain the some level of
consistency?
If so, are you including Non-Specific Subordinate References or child family
members in the numSubordinates count? Whilst NSSR and child family members
are both X.500 things, LDAP based Internet Drafts of each have existed at
some point in the past.


Regards,
Andrew Sciberras
Adacel Technologies.


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Mon Nov  3 06:52:20 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28370
	for <ldapext-archive@lists.ietf.org>; Mon, 3 Nov 2003 06:52:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGdFY-0008OD-9E; Mon, 03 Nov 2003 06:52:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGdEq-0008Ng-3n
	for ldapext@optimus.ietf.org; Mon, 03 Nov 2003 06:51:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28347
	for <ldapext@ietf.org>; Mon, 3 Nov 2003 06:51:03 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGdEl-0004EB-00
	for ldapext@ietf.org; Mon, 03 Nov 2003 06:51:11 -0500
Received: from david.siemens.de ([192.35.17.14])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGdEl-0004E0-00
	for ldapext@ietf.org; Mon, 03 Nov 2003 06:51:11 -0500
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14])
	by david.siemens.de (8.11.7/8.11.7) with ESMTP id hA3Bp6p02951;
	Mon, 3 Nov 2003 12:51:06 +0100 (MET)
Received: from pappel.asw.mchp.siemens.de ([139.25.160.30])
	by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id hA3Bp4d28936;
	Mon, 3 Nov 2003 12:51:05 +0100 (MET)
Received: by pappel.asw.mchp.siemens.de with Internet Mail Service (5.5.2657.72)
	id <V9874GWN>; Mon, 3 Nov 2003 12:51:04 +0100
Message-ID: <D1533D42A5A9D511A8090050DA3D8357844341@pappel.asw.mchp.siemens.de>
From: "Volpers, Helmut" <helmut.volpers@siemens.com>
To: "'andrews@adacel.com.au'" <andrews@adacel.com.au>,
        "Ldapext (E-mail)"
	 <ldapext@ietf.org>
Subject: RE: [ldapext] draft-ietf-boreham-numsubordinates-01.txt
Date: Mon, 3 Nov 2003 12:51:03 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>

Hi,


> -----Original Message-----
> From: Andrew Sciberras [mailto:andrews@adacel.com.au] 
> Sent: Monday, November 03, 2003 12:37 AM
> To: Ldapext (E-mail)
> Subject: RE: [ldapext] draft-ietf-boreham-numsubordinates-01.txt
> 
> 
> >I feel that numsubordinates should return 0 when 
> hassubordinates would 
> >return FALSE.  Since hassubordinates can include subentries, 
> >numsubordinates should also.
> >
> >John  McMeeking
> >
> 
> 
> Hi,
> 
> I think that subentries should not be included in the 
> numSubordinates count.

I disagree.
> 
> If a use-case for the numSubordinates is to aid a GUI in 
> deciding (for browsing purposes) if an entry is a leaf, then 
> returning 0 (zero) for an entry with one or more subentry's 
> and zero subordinate entries is acceptable. This is because, 
> under your general browsing and searching type operations, 
> subentries are not considered. If the GUI was being used for 
> Administrative purposes, where subentries may wish to be 
> explored, then simply checking if the entry is an 
> administrative point should accomplish this.

I think normal user applications will not use this feature today and they 
don't need it in future. The GUI for administrative purposes will use
this feature and they will display the subentries also.
> 
> 
> Another possible use-case for the numSubordinates attribute, 
> which has been expressed on this list, is for making 
> decisions as to whether the entry is a leaf for deletion 
> purposes. Ludovic correctly pointed out that having 
> numSubordinates == 0 and getting a NON_LEAF error when 
> deleting would be confusing. I don't believe a use-case of 
> numSubordinates should be to identify if an entry is a leaf 
> for deletion purposes.

I agree.

 Aside from ignoring subentries, the 
> scenario of numSubordinates == 0 and a NON_LEAF error will 
> occur when the user does not have sufficient permissions for 
> the subordinate entries to be included within the 
> numSubordinates count.
> 
> On the topic of access control... The draft states:
> 'Servers MUST ensure that the value returned in the 
> numSubordinates attribute to clients is consistent with the 
> view that client has of other server contents.' 

I don't like this. What means consistent with the view that client has ?

It has been 
> established that this means that Access Controls should be 
> taken into consideration when returning the numSubordinates 
> value. I think the draft should be a little more specific 
> though. Depending on what the intended use-case of 
> numSubordinates is, a statement should exist regarding which 
> permissions should be assessed when returning a 
> numSubordinates value. E.g..

I think the numSubordinates is a operational attribute and a administrator
can put access  rights on this attribute, but if this attribute is granted
to
read then it should return the numSubordinates value and not different
values 
dependant of the rights.

> * Is the decision based on modify or read permissions?
> * What happens if the entry's DN can be returned in a search, 
> but the user is not allowed to browse its contents?
> * Which Access Control specification are we referring to? 
> (BAC as defined in X501, or the old 
> draft-ietf-ldapext-acl-model-xx.txt)

Make it independent of the Access Control.
> 
> 
> Not including subentries within the numSubordinates count 
> does introduce an inconsistency between the numSubordinates 
> and hasSubordinates attributes. Is it the intention of this 
> specification to maintain the some level of consistency? If 
> so, are you including Non-Specific Subordinate References or 
> child family members in the numSubordinates count? Whilst 
> NSSR and child family members are both X.500 things, LDAP 
> based Internet Drafts of each have existed at some point in the past.

I think nobody have implemented NSSR's and if you have child family members
it is the decision of the Server whether numsubordinates is counted with
"1" for one family or with the number of childs.


Regards

Helmut
> 

> 
> Regards,
> Andrew Sciberras
> Adacel Technologies.
> 
> 
> _______________________________________________
> 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-admin@ietf.org  Mon Nov  3 08:09:22 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00486
	for <ldapext-archive@lists.ietf.org>; Mon, 3 Nov 2003 08:09:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGeS5-00047T-73; Mon, 03 Nov 2003 08:09:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGeR7-000469-EU
	for ldapext@optimus.ietf.org; Mon, 03 Nov 2003 08:08:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00446
	for <ldapext@ietf.org>; Mon, 3 Nov 2003 08:07:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGeR6-0005EQ-00
	for ldapext@ietf.org; Mon, 03 Nov 2003 08:08:00 -0500
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGeR5-0005Ds-00
	for ldapext@ietf.org; Mon, 03 Nov 2003 08:07:59 -0500
Received: from [172.16.1.246] (shiny.isode.com [62.3.217.250]) by rufus.isode.com
          via TCP (with SMTP (internal)) with ESMTPA
          for <ldapext@ietf.org>;
          Mon, 3 Nov 2003 13:08:15 +0000
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Mon, 03 Nov 2003 13:07:20 +0000
Subject: Re: [ldapext] Re: draft-ietf-boreham-numsubordinates-01.txt
From: Chris Ridd <chris.ridd@isode.com>
To: <ldapext@ietf.org>
Message-ID: <BBCC0388.AFBBA%chris.ridd@isode.com>
In-Reply-To: <3FA27CDA.1060409@stroeder.com>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

On 31/10/03 3:16 pm, Michael Str=F6der <michael@stroeder.com> wrote:
> John McMeeking wrote:
>>=20
>> I feel that numsubordinates should return 0 when hassubordinates would
>> return FALSE.  Since hassubordinates can include subentries,
>> numsubordinates should also.
>=20
> Ok, I agree with that.
>=20
> Ciao, Michael.

Since one of the draft's authors is our CEO, I should add that our DSA work=
s
this way. The hasSubordinates value is only TRUE when numSubordinates is
non-zero.

Cheers,

Chris


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Tue Nov 11 02:21:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22195
	for <ldapext-archive@lists.ietf.org>; Tue, 11 Nov 2003 02:21:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJSpj-0000cB-Ee; Tue, 11 Nov 2003 02:21:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJSoq-0000Zl-2X
	for ldapext@optimus.ietf.org; Tue, 11 Nov 2003 02:20:08 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22042
	for <ldapext@ietf.org>; Tue, 11 Nov 2003 02:19:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJSom-0006eK-00
	for ldapext@ietf.org; Tue, 11 Nov 2003 02:20:04 -0500
Received: from du-006-149.access.de.clara.net ([212.82.229.149] helo=nb2.stroeder.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJSok-0006e5-00
	for ldapext@ietf.org; Tue, 11 Nov 2003 02:20:03 -0500
Received: from localhost (localhost [127.0.0.1])
	by nb2.stroeder.com (Postfix) with ESMTP id 1F14B8C23E
	for <ldapext@ietf.org>; Tue, 11 Nov 2003 07:55:39 +0100 (CET)
Received: from stroeder.com (localhost [127.0.0.1])
	by nb2.stroeder.com (Postfix) with ESMTP id 2E19A8C241
	for <ldapext@ietf.org>; Tue, 11 Nov 2003 07:55:36 +0100 (CET)
Message-ID: <3FB087E7.6010605@stroeder.com>
Date: Tue, 11 Nov 2003 07:55:35 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: "Ldapext (E-mail)" <ldapext@ietf.org>
Subject: Re: [ldapext] draft-ietf-boreham-numsubordinates-01.txt
References: <04bf01c3a19a$3dcff420$a618200a@mtwav.adacel.com.au>
In-Reply-To: <04bf01c3a19a$3dcff420$a618200a@mtwav.adacel.com.au>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Content-Transfer-Encoding: 7bit
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Andrew Sciberras wrote:
> 
> On the topic of access control... The draft states:
> 'Servers MUST ensure that the value returned in the numSubordinates
> attribute to clients is consistent with the view that client has of other
> server contents.'
> It has been established that this means that Access Controls should be taken
> into consideration when returning the numSubordinates value.
> I think the draft should be a little more specific though. Depending on what
> the intended use-case of numSubordinates is, a statement should exist
> regarding which permissions should be assessed when returning a
> numSubordinates value.
> E.g..
> * Is the decision based on modify or read permissions?
> * What happens if the entry's DN can be returned in a search, but the user
> is not allowed to browse its contents?
> * Which Access Control specification are we referring to? (BAC as defined in
> X501, or the old draft-ietf-ldapext-acl-model-xx.txt)

You're raising some interesting issues regarding access control. After 
thinking about it I'd like to see that the statement above removed from the 
draft. The value of numSubordinates should not try to reflect the client's view.

Ciao, Michael.


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Tue Nov 11 02:50:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23404
	for <ldapext-archive@lists.ietf.org>; Tue, 11 Nov 2003 02:50:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJTHm-0002S7-Mw; Tue, 11 Nov 2003 02:50:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJTHd-0002Rh-SL
	for ldapext@optimus.ietf.org; Tue, 11 Nov 2003 02:49:53 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23398
	for <ldapext@ietf.org>; Tue, 11 Nov 2003 02:49:41 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJTHZ-0007AD-00
	for ldapext@ietf.org; Tue, 11 Nov 2003 02:49:49 -0500
Received: from server1.montana.boreham.org ([63.112.219.168] helo=toad.mtbrook.boreham.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJTHZ-0007AA-00
	for ldapext@ietf.org; Tue, 11 Nov 2003 02:49:49 -0500
Received: from racoon (unknown [63.112.219.189])
	by toad.mtbrook.boreham.org (Postfix) with ESMTP id 7B4203F8A
	for <ldapext@ietf.org>; Mon, 10 Nov 2003 23:49:19 -0800 (PST)
Message-ID: <000d01c3a828$5ce9f2e0$bddb703f@mtbrook.boreham.org>
From: "David Boreham" <david_list@boreham.org>
To: "Ldapext (E-mail)" <ldapext@ietf.org>
References: <04bf01c3a19a$3dcff420$a618200a@mtwav.adacel.com.au> <3FB087E7.6010605@stroeder.com>
Subject: Re: [ldapext] draft-ietf-boreham-numsubordinates-01.txt
Date: Mon, 10 Nov 2003 23:49:34 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 7bit
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

> You're raising some interesting issues regarding access control. After
> thinking about it I'd like to see that the statement above removed from
the
> draft. The value of numSubordinates should not try to reflect the client's
view.

The original motivation behind the statement in question was
to avoid leaking information otherwise restricted by access control,
via the numSubordinates attribute.

Of course any implementation which actually does generate
a different numSubordinates value depending upon access
control to the subordinate entries is likely to be rather inefficient.

I'm not aware of an implementation which actually does this.

So provided there aren't objections, I'm happy to remove the
statement.

It may be appropriate to add something to the effect that
access to the numSubordinates attribute by a client may
compromise attempts to restrict access to the subordinate tree.

I don't believe that the specific access control mechanism
matters here (but correct me if I'm wrong).





_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Tue Nov 11 03:09:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23696
	for <ldapext-archive@lists.ietf.org>; Tue, 11 Nov 2003 03:09:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJTa9-0003RT-GZ; Tue, 11 Nov 2003 03:09:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJTZk-0003Qx-EH
	for ldapext@optimus.ietf.org; Tue, 11 Nov 2003 03:08:36 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23681
	for <ldapext@ietf.org>; Tue, 11 Nov 2003 03:08:23 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJTZg-0007It-00
	for ldapext@ietf.org; Tue, 11 Nov 2003 03:08:32 -0500
Received: from du-006-247.access.de.clara.net ([212.82.229.247] helo=nb2.stroeder.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJTZf-0007Ip-00
	for ldapext@ietf.org; Tue, 11 Nov 2003 03:08:31 -0500
Received: from localhost (localhost [127.0.0.1])
	by nb2.stroeder.com (Postfix) with ESMTP
	id 91BA27F33D; Tue, 11 Nov 2003 09:07:11 +0100 (CET)
Received: from stroeder.com (localhost [127.0.0.1])
	by nb2.stroeder.com (Postfix) with ESMTP
	id 8430F1D753; Tue, 11 Nov 2003 09:07:10 +0100 (CET)
Message-ID: <3FB098AD.5090008@stroeder.com>
Date: Tue, 11 Nov 2003 09:07:09 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: David Boreham <david_list@boreham.org>
Cc: "Ldapext (E-mail)" <ldapext@ietf.org>
Subject: Re: [ldapext] draft-ietf-boreham-numsubordinates-01.txt
References: <04bf01c3a19a$3dcff420$a618200a@mtwav.adacel.com.au> <3FB087E7.6010605@stroeder.com> <000d01c3a828$5ce9f2e0$bddb703f@mtbrook.boreham.org>
In-Reply-To: <000d01c3a828$5ce9f2e0$bddb703f@mtbrook.boreham.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: by AMaViS 0.3.12pre8
Content-Transfer-Encoding: quoted-printable
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

David Boreham wrote:
 >Michael Str=F6der wrote:
>>You're raising some interesting issues regarding access control. After
>>thinking about it I'd like to see that the statement above removed from=

>>thedraft. The value of numSubordinates should not try to reflect the cl=
ient's
>>view.
>=20
> The original motivation behind the statement in question was
> to avoid leaking information otherwise restricted by access control,
> via the numSubordinates attribute.

But this can't be achieved without raising serious implementation issues.=


> It may be appropriate to add something to the effect that
> access to the numSubordinates attribute by a client may
> compromise attempts to restrict access to the subordinate tree.

Simply add a note under security considerations. One can easily configure=
=20
access control like to any other attribute.

Ciao, Michael.


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Tue Nov 11 15:36:28 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20785
	for <ldapext-archive@lists.ietf.org>; Tue, 11 Nov 2003 15:36:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJfF3-0002aj-Po; Tue, 11 Nov 2003 15:36:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJfEH-0002XU-OU
	for ldapext@optimus.ietf.org; Tue, 11 Nov 2003 15:35:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20743
	for <ldapext@ietf.org>; Tue, 11 Nov 2003 15:35:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJfEG-0001hI-00
	for ldapext@ietf.org; Tue, 11 Nov 2003 15:35:12 -0500
Received: from prv-mail20.provo.novell.com ([137.65.81.122])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJfEF-0001gk-00
	for ldapext@ietf.org; Tue, 11 Nov 2003 15:35:11 -0500
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com
	with Novell_GroupWise; Tue, 11 Nov 2003 13:34:41 -0700
Message-Id: <sfb0e571.080@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta
Date: Tue, 11 Nov 2003 13:33:54 -0700
From: "Jim Sermersheim" <jimse@novell.com>
To: <ldapext@ietf.org>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=__Part035D80A2.0__="
Subject: [ldapext] draft-zeilenga-ldap-adlist-06.txt
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>

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.

--=__Part035D80A2.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

This draft allows the search attribute selection list to be specified as
all attributes allowed by a given object class.
 
It may be useful to allow the distinction between all user attributes
allowed by a given obejct class and all operational attributes allowed
by a given object class.
 
We could alter the draft to state that +<objectClass> would specify all
user attributes, while *<objectClass> would specify all operational
attributes.
 
Comments?
 
Jim

--=__Part035D80A2.0__=
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4933.1800" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Microsoft Sans Serif">
<DIV>This draft allows the search attribute selection list to be specified as all attributes allowed by a given object class.</DIV>
<DIV>&nbsp;</DIV>
<DIV>It may be useful to allow the distinction between all user attributes allowed by a given obejct class and all operational attributes allowed by a given object class.</DIV>
<DIV>&nbsp;</DIV>
<DIV>We could alter the draft to state that +&lt;objectClass&gt; would specify all user attributes, while *&lt;objectClass&gt; would specify all operational attributes.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Comments?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Jim</DIV></BODY></HTML>
--=__Part035D80A2.0__=--

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Tue Nov 11 16:04:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21969
	for <ldapext-archive@lists.ietf.org>; Tue, 11 Nov 2003 16:04:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJfg8-0004mB-6B; Tue, 11 Nov 2003 16:04:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJfg1-0004lp-7S
	for ldapext@optimus.ietf.org; Tue, 11 Nov 2003 16:03:53 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21891
	for <ldapext@ietf.org>; Tue, 11 Nov 2003 16:03:41 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJffz-00027I-00
	for ldapext@ietf.org; Tue, 11 Nov 2003 16:03:51 -0500
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJffy-00026E-00
	for ldapext@ietf.org; Tue, 11 Nov 2003 16:03:50 -0500
Received: from odin.France.Sun.COM ([129.157.174.8])
	by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hABL3JUP017115;
	Tue, 11 Nov 2003 13:03:19 -0800 (PST)
Received: from Sun.COM (vpn-129-156-96-90.EMEA.Sun.COM [129.156.96.90])
	by odin.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id hABL3HP21176;
	Tue, 11 Nov 2003 22:03:17 +0100 (MET)
Message-ID: <3FB14E4E.5080609@Sun.COM>
Date: Tue, 11 Nov 2003 22:02:06 +0100
From: Ludovic Poitou <ludovic.poitou@Sun.COM>
Organization: SUN Microsystems
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jim Sermersheim <jimse@novell.com>
CC: ldapext@ietf.org
Subject: Re: [ldapext] draft-zeilenga-ldap-adlist-06.txt
References: <sfb0e571.080@prv-mail20.provo.novell.com>
In-Reply-To: <sfb0e571.080@prv-mail20.provo.novell.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Jim Sermersheim wrote:

> This draft allows the search attribute selection list to be specified 
> as all attributes allowed by a given object class.
>  
> It may be useful to allow the distinction between all user attributes 
> allowed by a given obejct class and all operational attributes allowed 
> by a given object class.
>  
> We could alter the draft to state that +<objectClass> would specify 
> all user attributes, while *<objectClass> would specify all 
> operational attributes.

Somehow, it would be better if the + sign and * sign apply to the same 
type of attributes in all cases...
So far * means all users attributes. So *<objectclass> should specific 
all user attributes allowed by the objectclass, and +<objectclass> would 
specify all operational attributes.

Ludovic.

>  
> Comments?
>  
> Jim


-- 
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-admin@ietf.org  Tue Nov 11 16:09:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22213
	for <ldapext-archive@lists.ietf.org>; Tue, 11 Nov 2003 16:09:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJfkz-0005Ns-8L; Tue, 11 Nov 2003 16:09:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AJfkC-0005Ho-RE
	for ldapext@optimus.ietf.org; Tue, 11 Nov 2003 16:08:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22138
	for <ldapext@ietf.org>; Tue, 11 Nov 2003 16:08:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJfkB-0002CE-00
	for ldapext@ietf.org; Tue, 11 Nov 2003 16:08:11 -0500
Received: from prv-mail20.provo.novell.com ([137.65.81.122])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AJfkA-0002C0-00
	for ldapext@ietf.org; Tue, 11 Nov 2003 16:08:10 -0500
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com
	with Novell_GroupWise; Tue, 11 Nov 2003 14:07:39 -0700
Message-Id: <sfb0ed2b.077@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta
Date: Tue, 11 Nov 2003 14:07:08 -0700
From: "Jim Sermersheim" <jimse@novell.com>
To: <ldapext@ietf.org>
Subject: Re: [ldapext] draft-zeilenga-ldap-adlist-06.txt
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=__PartC59B466C.0__="
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>

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.

--=__PartC59B466C.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Yeah, I got it reversed.
 
Jim

>>> Ludovic Poitou <ludovic.poitou@Sun.COM> 11/11/03 3:02:06 PM >>>


Jim Sermersheim wrote:

> This draft allows the search attribute selection list to be specified

> as all attributes allowed by a given object class.
> 
> It may be useful to allow the distinction between all user attributes

> allowed by a given obejct class and all operational attributes
allowed 
> by a given object class.
> 
> We could alter the draft to state that +<objectClass> would specify 
> all user attributes, while *<objectClass> would specify all 
> operational attributes.

Somehow, it would be better if the + sign and * sign apply to the same

type of attributes in all cases...
So far * means all users attributes. So *<objectclass> should specific

all user attributes allowed by the objectclass, and +<objectclass>
would 
specify all operational attributes.

Ludovic.

> 
> Comments?
> 
> Jim


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




--=__PartC59B466C.0__=
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4933.1800" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Microsoft Sans Serif">
<DIV>Yeah, I got it reversed.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Jim<BR><BR>&gt;&gt;&gt; Ludovic Poitou &lt;ludovic.poitou@Sun.COM&gt; 11/11/03 3:02:06 PM &gt;&gt;&gt;<BR><BR><BR>Jim Sermersheim wrote:<BR><BR>&gt; This draft allows the search attribute selection list to be specified <BR>&gt; as all attributes allowed by a given object class.<BR>&gt; <BR>&gt; It may be useful to allow the distinction between all user attributes <BR>&gt; allowed by a given obejct class and all operational attributes allowed <BR>&gt; by a given object class.<BR>&gt; <BR>&gt; We could alter the draft to state that +&lt;objectClass&gt; would specify <BR>&gt; all user attributes, while *&lt;objectClass&gt; would specify all <BR>&gt; operational attributes.<BR><BR>Somehow, it would be better if the + sign and * sign apply to the same <BR>type of attributes in all cases...<BR>So far * means all users attributes. So *&lt;objectclass&gt; should specific <BR>all user attributes allowed by the objectclass, and +&lt;objectclass&gt; would <BR>specify all operation!
 al attributes.<BR><BR>Ludovic.<BR><BR>&gt; <BR>&gt; Comments?<BR>&gt; <BR>&gt; Jim<BR><BR><BR>-- <BR>Ludovic Poitou<BR>Directory Architect.<BR>Directory Server Group, Grenoble, France<BR>Sun Microsystems Inc.<BR><BR>Sun Microsystems requires the following notice:<BR>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<BR>NOTICE: This email message is for the sole use of the intended<BR>recipient(s) and may contain confidential and privileged<BR>information. Any unauthorized review, use, disclosure or<BR>distribution is prohibited. If you are not the intended<BR>recipient, please contact the sender by reply email and destroy<BR>all copies of the original message.<BR>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<BR><BR><BR></DIV></BODY></HTML>
--=__PartC59B466C.0__=--

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Thu Nov 13 10:26:32 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02728
	for <ldapext-archive@lists.ietf.org>; Thu, 13 Nov 2003 10:26:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKJMB-0003Ac-DW; Thu, 13 Nov 2003 10:26:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKJLz-0003A5-Kz
	for ldapext@optimus.ietf.org; Thu, 13 Nov 2003 10:25:51 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02686
	for <ldapext@ietf.org>; Thu, 13 Nov 2003 10:25:38 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKJLx-0006pQ-00
	for ldapext@ietf.org; Thu, 13 Nov 2003 10:25:49 -0500
Received: from router.boolean.net
	([198.144.206.49] helo=pretender.boolean.net ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKJLw-0006pD-00
	for ldapext@ietf.org; Thu, 13 Nov 2003 10:25:48 -0500
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1])
	by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hADFPblg035870;
	Thu, 13 Nov 2003 15:25:38 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <6.0.0.22.0.20031113091153.043d4b60@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
Date: Thu, 13 Nov 2003 09:25:03 -0600
To: "Jim Sermersheim" <jimse@novell.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: [ldapext] draft-zeilenga-ldap-adlist-06.txt
Cc: <ldapext@ietf.org>
In-Reply-To: <sfb0e571.080@prv-mail20.provo.novell.com>
References: <sfb0e571.080@prv-mail20.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>

At 02:33 PM 11/11/2003, Jim Sermersheim wrote:
>This draft allows the search attribute selection list to be specified as all attributes allowed by a given object class.
> 
>It may be useful to allow the distinction between all user attributes allowed by a given obejct class and all operational attributes allowed by a given object class.

While that may be useful, I rather keep this mechanism a simple short hand.
That is, I prefer a mechanism where the input can be expanded to the output
list of attribute types identifiers without having to know the particulars
of these attribute types.

Kurt



_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Fri Nov 14 16:08:26 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29437
	for <ldapext-archive@lists.ietf.org>; Fri, 14 Nov 2003 16:08:25 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKlAf-0000Hh-2o; Fri, 14 Nov 2003 16:08:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKlAN-0000Cn-W1
	for ldapext@optimus.ietf.org; Fri, 14 Nov 2003 16:07:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29402
	for <ldapext@ietf.org>; Fri, 14 Nov 2003 16:07:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKlAM-0004KO-00
	for ldapext@ietf.org; Fri, 14 Nov 2003 16:07:42 -0500
Received: from e5.ny.us.ibm.com ([32.97.182.105])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKlAL-0004KA-00
	for ldapext@ietf.org; Fri, 14 Nov 2003 16:07:41 -0500
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hAEL7Bn9563766
	for <ldapext@ietf.org>; Fri, 14 Nov 2003 16:07:11 -0500
Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAEL79gI227438
	for <ldapext@ietf.org>; Fri, 14 Nov 2003 16:07:09 -0500
To: ldapext@ietf.org
X-Mailer: Lotus Notes Release 5.0.12   February 13, 2003
Message-ID: <OF5E2A74AA.0C607031-ON86256DDE.0072EACD-86256DDE.007402F4@us.ibm.com>
From: John McMeeking <jmcmeek@us.ibm.com>
Date: Fri, 14 Nov 2003 15:07:08 -0600
X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.5|September 18, 2003) at
 11/14/2003 03:07:09 PM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: [ldapext] draft-behera-ldap-password-policy - bind behavior when pwd must be changed
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>





As I read this draft, if the password must be changed (after reset), the
bind is successful, even if the client does not include the password policy
request control.  This seems like a problem when the LDAP server is used
only for authentication.  I would think that a bind in that case should
fail -- on the assumption that there is a password policy aware application
that can be used to change the password.  Otherwise, the user can continue
to authenticate successfully, which seems to be in violation of the intent
of the policy.

Should the bind procedure be changed to fail if the password must be
changed because of being reset when there is no password policy control?
And succeed, with the warning, if the control is present?  I'd be tempted
to say even then it should fail, but I'm not sure if clients like JNDI
would be able to handle a control on a failure.  Or at least this concern
discussed, possibly with the recommendation that servers should provide a
means to chose this behavior?


John  McMeeking


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Fri Nov 14 18:14:17 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04460
	for <ldapext-archive@lists.ietf.org>; Fri, 14 Nov 2003 18:14:17 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKn8a-0001cI-V3; Fri, 14 Nov 2003 18:14:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AKn8L-0001c4-W4
	for ldapext@optimus.ietf.org; Fri, 14 Nov 2003 18:13:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04384
	for <ldapext@ietf.org>; Fri, 14 Nov 2003 18:13:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKn8I-00069G-00
	for ldapext@ietf.org; Fri, 14 Nov 2003 18:13:42 -0500
Received: from brmea-mail-2.sun.com ([192.18.98.43])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AKn8I-00069D-00
	for ldapext@ietf.org; Fri, 14 Nov 2003 18:13:42 -0500
Received: from odin.France.Sun.COM ([129.157.174.8])
	by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAENDePh004676;
	Fri, 14 Nov 2003 16:13:41 -0700 (MST)
Received: from Sun.COM (vpn-129-156-96-43.EMEA.Sun.COM [129.156.96.43])
	by odin.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id hAENDdP01981;
	Sat, 15 Nov 2003 00:13:39 +0100 (MET)
Message-ID: <3FB5615C.9020904@Sun.COM>
Date: Sat, 15 Nov 2003 00:12:28 +0100
From: Ludovic Poitou <ludovic.poitou@Sun.COM>
Organization: SUN Microsystems
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John McMeeking <jmcmeek@us.ibm.com>
CC: ldapext@ietf.org
Subject: Re: [ldapext] draft-behera-ldap-password-policy - bind behavior when
 pwd must be changed
References: <OF5E2A74AA.0C607031-ON86256DDE.0072EACD-86256DDE.007402F4@us.ibm.com>
In-Reply-To: <OF5E2A74AA.0C607031-ON86256DDE.0072EACD-86256DDE.007402F4@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



John McMeeking wrote:

>
>
>As I read this draft, if the password must be changed (after reset), the
>bind is successful, even if the client does not include the password policy
>request control.  This seems like a problem when the LDAP server is used
>only for authentication.  I would think that a bind in that case should
>fail -- on the assumption that there is a password policy aware application
>that can be used to change the password.  Otherwise, the user can continue
>to authenticate successfully, which seems to be in violation of the intent
>of the policy.
>
>  
>
Good remark.

>Should the bind procedure be changed to fail if the password must be
>changed because of being reset when there is no password policy control?
>And succeed, with the warning, if the control is present? 
>
I'd be tempted to say yes.
I also concur that this should be a SHOULD.
I believe that it will take a while before all clients use the password 
policy controls on all bind operations.

I will update the draft to discuss this issue and provide some 
recommandations.

Thanks for your comments,

Ludovic.

> I'd be tempted
>to say even then it should fail, but I'm not sure if clients like JNDI
>would be able to handle a control on a failure.  Or at least this concern
>discussed, possibly with the recommendation that servers should provide a
>means to chose this behavior?
>
>
>John  McMeeking
>
>
>_______________________________________________
>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-admin@ietf.org  Mon Nov 17 04:18:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06080
	for <ldapext-archive@lists.ietf.org>; Mon, 17 Nov 2003 04:18:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALfWD-0007QQ-GE; Mon, 17 Nov 2003 04:18:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALfVj-0007Q1-5H
	for ldapext@optimus.ietf.org; Mon, 17 Nov 2003 04:17:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06052
	for <ldapext@ietf.org>; Mon, 17 Nov 2003 04:17:18 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALfVg-0003mq-00
	for ldapext@ietf.org; Mon, 17 Nov 2003 04:17:28 -0500
Received: from du-006-174.access.de.clara.net ([212.82.229.174] helo=nb2.stroeder.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALfVe-0003mn-00
	for ldapext@ietf.org; Mon, 17 Nov 2003 04:17:27 -0500
Received: from localhost (localhost [127.0.0.1])
	by nb2.stroeder.com (Postfix) with ESMTP
	id 2D0752C3B7; Mon, 17 Nov 2003 09:37:35 +0100 (CET)
Received: from stroeder.com (localhost [127.0.0.1])
	by nb2.stroeder.com (Postfix) with ESMTP
	id D824511174; Mon, 17 Nov 2003 09:37:33 +0100 (CET)
Message-ID: <3FB888CD.2070703@stroeder.com>
Date: Mon, 17 Nov 2003 09:37:33 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: John McMeeking <jmcmeek@us.ibm.com>
Cc: ldapext@ietf.org
Subject: Re: [ldapext] draft-behera-ldap-password-policy - bind behavior when
 pwd must be changed
References: <OF5E2A74AA.0C607031-ON86256DDE.0072EACD-86256DDE.007402F4@us.ibm.com>
In-Reply-To: <OF5E2A74AA.0C607031-ON86256DDE.0072EACD-86256DDE.007402F4@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Content-Transfer-Encoding: 7bit
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

John McMeeking wrote:
> 
> Should the bind procedure be changed to fail if the password must be
> changed because of being reset when there is no password policy control?

Yes.

> And succeed, with the warning, if the control is present?

No.

> I'd be tempted to say even then it should fail,

I agree.

> but I'm not sure if clients like JNDI
> would be able to handle a control on a failure.

I wouldn't care.

>  Or at least this concern
> discussed, possibly with the recommendation that servers should provide a
> means to chose this behavior?

I would not leave this open to server configuation. There should be exactly 
one way to do it.

Ciao, Michael.


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Mon Nov 17 16:40:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07017
	for <ldapext-archive@lists.ietf.org>; Mon, 17 Nov 2003 16:40:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALr6H-0007vP-IG; Mon, 17 Nov 2003 16:40:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALr5N-0007uS-Uz
	for ldapext@optimus.ietf.org; Mon, 17 Nov 2003 16:39:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06974
	for <ldapext@ietf.org>; Mon, 17 Nov 2003 16:38:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALr5L-0006o1-00
	for ldapext@ietf.org; Mon, 17 Nov 2003 16:39:03 -0500
Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALr5K-0006mm-00
	for ldapext@ietf.org; Mon, 17 Nov 2003 16:39:02 -0500
Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16)
	id <B0001a599f>; Tue, 18 Nov 2003 08:31:39 +1100
Received: (qmail 13969 invoked from network); 17 Nov 2003 21:38:30 -0000
Received: from unknown (HELO shylock) (10.32.24.166)
  by nexus.adacel.com with SMTP; 17 Nov 2003 21:38:30 -0000
Reply-To: <andrews@adacel.com.au>
From: "Andrew Sciberras" <andrews@adacel.com.au>
To: "Ldapext \(E-mail\)" <ldapext@ietf.org>
Cc: "=?iso-8859-1?Q?'Michael_Str=F6der'?=" <michael@stroeder.com>,
        "'John McMeeking'" <jmcmeek@us.ibm.com>,
        "'Ludovic Poitou'" <ludovic.poitou@Sun.COM>
Subject: RE: [ldapext] draft-behera-ldap-password-policy - bind behavior when pwd must be changed
Date: Tue, 18 Nov 2003 08:38:30 +1100
Message-ID: <022b01c3ad53$25854e50$a618200a@mtwav.adacel.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3FB888CD.2070703@stroeder.com>
Content-Transfer-Encoding: 7bit
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

G'Day!

Purhaps i've misunderstood something, but I have a little trouble agreeing
with the arguments that have been made in this discussion.

I do agree that in the current state of the draft, the 'change after reset'
feature does not accomidate for LDAP Server's being used for authentication
into other systems.
However, failing bind operations is certainly not the solution.

Imagine all the LDAP server's which use the bind operation to authenticate
user's for the purpose of accessing the directory information.

Lets say a new user joins an organization and their password is
automatically set to their Date Of Birth by the administrator.
At the moment, the user would be able to bind to the directory and be
severly restricted in what they can do, until they change their password.
If the bind operation returned a failure, how do you propose that the user
is ever going to be able to change their password?

As far as I can tell, there are two ways that the password is ever going to
be changed.
1. By the user,
2. By someone else.

If we fail binds, the user can never be able to change the password
themselves since they would not be able to authenticate themselves to the
directory.
It would be entirely possible for someone else to change the password,
however this would be pointless. In the Adacel View500 implementation of
this draft, we have made the assumption that if a A's password is modified
by B, and B has sufficient access rights to modify A's password, then B is
an administrator.
This being the case, if B modified A's password for her, then the directory
would automatically reset the pwdReset value to TRUE.


On a different note, the description of pwdReset states the following:
"This attribute holds a flag to indicate (when TRUE) that the password has
been reset and therefore must be changed by the user on first
authentication."

I think this should be reworded to get rid of the 'first authentication'
part.
There is nothing in the draft that restricts a user from binding a million
times before changing their passwrod.

Regards,
Andrew Sciberras
Software Engineer
Adacel Technologies




_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Mon Nov 17 17:25:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09833
	for <ldapext-archive@lists.ietf.org>; Mon, 17 Nov 2003 17:25:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALrnp-0003N5-Py; Mon, 17 Nov 2003 17:25:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALrnO-0003Lc-Ts
	for ldapext@optimus.ietf.org; Mon, 17 Nov 2003 17:24:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09775
	for <ldapext@ietf.org>; Mon, 17 Nov 2003 17:24:21 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALrnM-000009-00
	for ldapext@ietf.org; Mon, 17 Nov 2003 17:24:32 -0500
Received: from e6.ny.us.ibm.com ([32.97.182.106])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALrnL-0007nf-00
	for ldapext@ietf.org; Mon, 17 Nov 2003 17:24:31 -0500
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hAHMNxVn511556
	for <ldapext@ietf.org>; Mon, 17 Nov 2003 17:23:59 -0500
Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAHMNwhl234172
	for <ldapext@ietf.org>; Mon, 17 Nov 2003 17:23:58 -0500
Subject: RE: [ldapext] draft-behera-ldap-password-policy - bind behavior when pwd
 must be changed
To: ldapext@ietf.org
X-Mailer: Lotus Notes Release 5.0.12   February 13, 2003
Message-ID: <OFE6C1B161.42EB0E17-ON86256DE1.007767F8-86256DE1.007B0C6E@us.ibm.com>
From: John McMeeking <jmcmeek@us.ibm.com>
Date: Mon, 17 Nov 2003 16:24:00 -0600
X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.5|September 18, 2003) at
 11/17/2003 04:23:58 PM
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable





Andrew,

Here's the situation that was described to me:

A web application is configured to authenticate to LDAP=2E  Somewhere u=
nder
the covers this translates into a bind request to the LDAP server=2E  I=

believe it is quite common for many "accounts" on LDAP servers to be us=
ed
in binds for only this purpose=2E

The administrator has enabled password policy on the LDAP server with t=
he
"password must be changed after [re]set" feature and creates a new acco=
unt
-- or resets the password of an existing account=2E  At this point the
account is now in a state where the user must change the password=2E

The web application, not knowing about password policy, issues a bind
request and gets a "success" result=2E  If this is the only way that a =
bind
is done to this account, the user can authenticate to the web applicati=
on
over and over without changing their password=2E  This seems to violate=
 the
intent of the "password must be changed after reset" setting=2E  If the=

connection were used for some other operation other than bind - or chan=
ging
the client's password - the client would get failures=2E

Thus my suggestion that the bind request ought to fail=2E  I don't beli=
eve
that authentication using a password that must be reset should succeed =
from
the perspective of the web application=2E  If the web application was
password policy aware, I'd expect it to tell the user that his password=

must be changed, provide an interface to change the password, and not a=
llow
any other actions=2E

In an environment where password policy has been set up in this way som=
e
set of tools would be provided to enable the user to change their passw=
ord,
most likely through an application that does know about password policy=

controls=2E  Alternately, I suppose the server could send a failure res=
ponse
to the client, but leave the connection in an authenticated state
sufficient to perform the change password request=2E  That would requir=
e the
client to recognize the failure and allow password changes -- still a
change, but possibly one that is easier to handle than installing a new=

client=2E  And there's probably nothing inherently wrong with an anonym=
ously
bound password change request, as long as it contains the old password =
and
is treated by server similar to a bind request and modify request (i=2E=
e=2E
audit attempts to change the password with wrong old password)=2E  Thes=
e seem
like policy decisions that can be left to the implementation=2E

Certainly, if the applications used to change passwords cannot be chang=
ed
to deal with these accounts, you're in trouble=2E  But you shouldn't be=
 using
this password policy then=2E


John  McMeeking



                                                                       =
                                             
                      "Andrew                                          =
                                             
                      Sciberras"               To:       "Ldapext \(E-m=
ail\)" <ldapext@ietf=2Eorg>                    
                      <andrews@adacel=2Ec        cc:       "'Michael St=
r=F6der'" <michael@stroeder=2Ecom>, John           
                      om=2Eau>                    McMeeking/Rochester/I=
BM@IBMUS, "'Ludovic Poitou'"                   
                                                <ludovic=2Epoitou@Sun=2E=
COM>                                            
                      11/17/2003 03:38         Subject:  RE: [ldapext] =
draft-behera-ldap-password-policy - bind     
                      PM                        behavior when pwd must =
be changed                                   
                      Please respond to                                =
                                             
                      andrews                                          =
                                             
                                                                       =
                                             
                                                                       =
                                             




G'Day!

Purhaps i've misunderstood something, but I have a little trouble agree=
ing
with the arguments that have been made in this discussion=2E

I do agree that in the current state of the draft, the 'change after re=
set'
feature does not accomidate for LDAP Server's being used for authentica=
tion
into other systems=2E
However, failing bind operations is certainly not the solution=2E

Imagine all the LDAP server's which use the bind operation to authentic=
ate
user's for the purpose of accessing the directory information=2E

Lets say a new user joins an organization and their password is
automatically set to their Date Of Birth by the administrator=2E
At the moment, the user would be able to bind to the directory and be
severly restricted in what they can do, until they change their passwor=
d=2E
If the bind operation returned a failure, how do you propose that the u=
ser
is ever going to be able to change their password?

As far as I can tell, there are two ways that the password is ever goin=
g to
be changed=2E
1=2E By the user,
2=2E By someone else=2E

If we fail binds, the user can never be able to change the password
themselves since they would not be able to authenticate themselves to t=
he
directory=2E
It would be entirely possible for someone else to change the password,
however this would be pointless=2E In the Adacel View500 implementation=
 of
this draft, we have made the assumption that if a A's password is modif=
ied
by B, and B has sufficient access rights to modify A's password, then B=
 is
an administrator=2E
This being the case, if B modified A's password for her, then the direc=
tory
would automatically reset the pwdReset value to TRUE=2E


On a different note, the description of pwdReset states the following:
"This attribute holds a flag to indicate (when TRUE) that the password =
has
been reset and therefore must be changed by the user on first
authentication=2E"

I think this should be reworded to get rid of the 'first authentication=
'
part=2E
There is nothing in the draft that restricts a user from binding a mill=
ion
times before changing their passwrod=2E

Regards,
Andrew Sciberras
Software Engineer
Adacel Technologies




=



_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Tue Nov 18 06:50:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18090
	for <ldapext-archive@lists.ietf.org>; Tue, 18 Nov 2003 06:50:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AM4Ms-0007P8-7M; Tue, 18 Nov 2003 06:50:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AM4MK-0007OA-Dg
	for ldapext@optimus.ietf.org; Tue, 18 Nov 2003 06:49:28 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18074
	for <ldapext@ietf.org>; Tue, 18 Nov 2003 06:49:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AM4MG-0003aC-00
	for ldapext@ietf.org; Tue, 18 Nov 2003 06:49:24 -0500
Received: from [213.221.78.189] (helo=nb2.stroeder.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AM4ME-0003a7-00
	for ldapext@ietf.org; Tue, 18 Nov 2003 06:49:23 -0500
Received: from localhost (localhost [127.0.0.1])
	by nb2.stroeder.com (Postfix) with ESMTP
	id 78FFA837FD; Tue, 18 Nov 2003 12:48:23 +0100 (CET)
Received: from stroeder.com (localhost [127.0.0.1])
	by nb2.stroeder.com (Postfix) with ESMTP
	id 58F3D6704C; Tue, 18 Nov 2003 12:48:22 +0100 (CET)
Message-ID: <3FBA0705.2@stroeder.com>
Date: Tue, 18 Nov 2003 12:48:21 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: John McMeeking <jmcmeek@us.ibm.com>
Cc: ldapext@ietf.org
Subject: Re: [ldapext] draft-behera-ldap-password-policy - bind behavior when
 pwd must be changed
References: <OFE6C1B161.42EB0E17-ON86256DE1.007767F8-86256DE1.007B0C6E@us.ibm.com>
In-Reply-To: <OFE6C1B161.42EB0E17-ON86256DE1.007767F8-86256DE1.007B0C6E@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Content-Transfer-Encoding: 7bit
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

I fully agree with John's analysis.

Ciao, Michael.

John McMeeking wrote:
> 
> 
> Andrew,
> 
> Here's the situation that was described to me:
> 
> A web application is configured to authenticate to LDAP.  Somewhere under
> the covers this translates into a bind request to the LDAP server.  I
> believe it is quite common for many "accounts" on LDAP servers to be used
> in binds for only this purpose.
> 
> The administrator has enabled password policy on the LDAP server with the
> "password must be changed after [re]set" feature and creates a new account
> -- or resets the password of an existing account.  At this point the
> account is now in a state where the user must change the password.
> 
> The web application, not knowing about password policy, issues a bind
> request and gets a "success" result.  If this is the only way that a bind
> is done to this account, the user can authenticate to the web application
> over and over without changing their password.  This seems to violate the
> intent of the "password must be changed after reset" setting.  If the
> connection were used for some other operation other than bind - or changing
> the client's password - the client would get failures.
> 
> Thus my suggestion that the bind request ought to fail.  I don't believe
> that authentication using a password that must be reset should succeed from
> the perspective of the web application.  If the web application was
> password policy aware, I'd expect it to tell the user that his password
> must be changed, provide an interface to change the password, and not allow
> any other actions.
> 
> In an environment where password policy has been set up in this way some
> set of tools would be provided to enable the user to change their password,
> most likely through an application that does know about password policy
> controls.  Alternately, I suppose the server could send a failure response
> to the client, but leave the connection in an authenticated state
> sufficient to perform the change password request.  That would require the
> client to recognize the failure and allow password changes -- still a
> change, but possibly one that is easier to handle than installing a new
> client.  And there's probably nothing inherently wrong with an anonymously
> bound password change request, as long as it contains the old password and
> is treated by server similar to a bind request and modify request (i.e.
> audit attempts to change the password with wrong old password).  These seem
> like policy decisions that can be left to the implementation.
> 
> Certainly, if the applications used to change passwords cannot be changed
> to deal with these accounts, you're in trouble.  But you shouldn't be using
> this password policy then.
>
>
>
> John  McMeeking



_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Tue Nov 18 16:27:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18024
	for <ldapext-archive@lists.ietf.org>; Tue, 18 Nov 2003 16:27:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMDNF-00017l-Aa; Tue, 18 Nov 2003 16:27:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMDMc-00015I-Tv
	for ldapext@optimus.ietf.org; Tue, 18 Nov 2003 16:26:23 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17892
	for <ldapext@ietf.org>; Tue, 18 Nov 2003 16:26:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMDMZ-0006in-00
	for ldapext@ietf.org; Tue, 18 Nov 2003 16:26:19 -0500
Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMDMX-0006gg-00
	for ldapext@ietf.org; Tue, 18 Nov 2003 16:26:18 -0500
Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16)
	id <B0001a6b25>; Wed, 19 Nov 2003 08:18:42 +1100
Received: (qmail 22779 invoked from network); 18 Nov 2003 21:25:40 -0000
Received: from unknown (HELO shylock) (10.32.24.166)
  by nexus.adacel.com with SMTP; 18 Nov 2003 21:25:40 -0000
Reply-To: <andrews@adacel.com.au>
From: "Andrew Sciberras" <andrews@adacel.com.au>
To: "=?iso-8859-1?Q?'Michael_Str=F6der'?=" <michael@stroeder.com>
Cc: "Ldapext \(E-mail\)" <ldapext@ietf.org>
Subject: RE: [ldapext] draft-behera-ldap-password-policy - bind behavior when pwd must be changed
Date: Wed, 19 Nov 2003 08:25:41 +1100
Message-ID: <029f01c3ae1a$858403b0$a618200a@mtwav.adacel.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3FBA0705.2@stroeder.com>
Content-Transfer-Encoding: 7bit
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Hi,

>
>I fully agree with John's analysis.
>

Thats cool, although I think my differing opinion comes from a certain level
of ambiguity within the draft.

The decription of pwdMustChange is :
"This attribute specifies with a value of "TRUE" that users must change
their passwords when they first bind to the directory after a password is
set or reset by the administrator."

And pwdReset is:
"This attribute holds a flag to indicate (when TRUE) that the password has
been reset and therefore must be changed by the user on first
authentication"

The problems are:
* Administrator is never defined
* The draft never states when the pwdReset value should be set to TRUE
* The draft doesn't account for the scenario of a reset password (ie.
pwdReset == TRUE) being changed by an Administrator again.


The assumptions i've taken from the draft, into my implemntation, is:
* An administrator is anyone with the power to change the user's password,
who isn't the user.
* If a password, which is being governed by a pwdMustChange policy, is
changed by my definition of an administrator then the pwdReset value will be
set to TRUE.
* If an administrator change dthe password again, the pwdReset value will
still be TRUE.


My implementation was based on my assumptions. And im my implementation, the
only way your going to get rid of that pwdReset value of TRUE is for the
user to change the password themselves, which requires a bind operation.

The only way that I can see your proposed solution working is if you and
other implementations have made different assumptions as to what an
administrator  is.
If this is the case, then I think we should aim to remove this level of
ambiguity from the draft.

Catch,
Andrew Sciberras.

>Ciao, Michael.



_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Wed Nov 19 00:11:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06833
	for <ldapext-archive@lists.ietf.org>; Wed, 19 Nov 2003 00:11:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMKcI-0000CC-22; Wed, 19 Nov 2003 00:11:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMKbl-0000Bb-0P
	for ldapext@optimus.ietf.org; Wed, 19 Nov 2003 00:10:29 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06778
	for <ldapext@ietf.org>; Wed, 19 Nov 2003 00:10:16 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMKbi-0000FZ-00
	for ldapext@ietf.org; Wed, 19 Nov 2003 00:10:26 -0500
Received: from manatick.foretec.com ([4.17.168.5] helo=manatick)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMKbh-0000FV-00
	for ldapext@ietf.org; Wed, 19 Nov 2003 00:10:26 -0500
Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com)
	by manatick with esmtp (Exim 4.24)
	id 1AMKbg-0007AU-LD
	for ldapext@ietf.org; Wed, 19 Nov 2003 00:10:24 -0500
Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16)
	id <B0001a7311>; Wed, 19 Nov 2003 16:01:51 +1100
Received: (qmail 31854 invoked from network); 19 Nov 2003 05:08:52 -0000
Received: from unknown (HELO adacel.com.au) (10.32.24.165)
  by nexus.adacel.com with SMTP; 19 Nov 2003 05:08:52 -0000
Message-ID: <3FBAFAE3.2030001@adacel.com.au>
Date: Wed, 19 Nov 2003 16:08:51 +1100
From: Steven Legg <steven.legg@adacel.com.au>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3.1) Gecko/20030425
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
CC: Jim Sermersheim <jimse@novell.com>, ldapext@ietf.org
Subject: Re: [ldapext] draft-zeilenga-ldap-adlist-06.txt
References: <sfb0e571.080@prv-mail20.provo.novell.com> <6.0.0.22.0.20031113091153.043d4b60@127.0.0.1>
In-Reply-To: <6.0.0.22.0.20031113091153.043d4b60@127.0.0.1>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


In my experience, user defined object classes reference only user attributes
and syntax schema object classes (e.g. subentry) reference mostly operational
attributes. Separate mechanisms for requesting only the user attributes or
only the operational attributes would not seem to achieve very much.

Regards,
Steven

Kurt D. Zeilenga wrote:
> At 02:33 PM 11/11/2003, Jim Sermersheim wrote:
> 
>>This draft allows the search attribute selection list to be specified as all attributes allowed by a given object class.
>>
>>It may be useful to allow the distinction between all user attributes allowed by a given obejct class and all operational attributes allowed by a given object class.
> 
> 
> While that may be useful, I rather keep this mechanism a simple short hand.
> That is, I prefer a mechanism where the input can be expanded to the output
> list of attribute types identifiers without having to know the particulars
> of these attribute types.
> 
> 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-admin@ietf.org  Wed Nov 19 00:21:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07310
	for <ldapext-archive@lists.ietf.org>; Wed, 19 Nov 2003 00:21:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMKlx-0000ir-HS; Wed, 19 Nov 2003 00:21:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMKlf-0000iN-Ml
	for ldapext@optimus.ietf.org; Wed, 19 Nov 2003 00:20:43 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07276
	for <ldapext@ietf.org>; Wed, 19 Nov 2003 00:20:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMKld-0000XE-00
	for ldapext@ietf.org; Wed, 19 Nov 2003 00:20:41 -0500
Received: from router.boolean.net
	([198.144.206.49] helo=pretender.boolean.net ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMKlc-0000X4-00
	for ldapext@ietf.org; Wed, 19 Nov 2003 00:20:40 -0500
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1])
	by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hAJ5KWlg015730;
	Wed, 19 Nov 2003 05:20:32 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <6.0.0.22.0.20031118211713.026faa90@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
Date: Tue, 18 Nov 2003 21:19:56 -0800
To: Steven Legg <steven.legg@adacel.com.au>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: [ldapext] draft-zeilenga-ldap-adlist-06.txt
Cc: Jim Sermersheim <jimse@novell.com>, ldapext@ietf.org
In-Reply-To: <3FBAFAE3.2030001@adacel.com.au>
References: <sfb0e571.080@prv-mail20.provo.novell.com>
 <6.0.0.22.0.20031113091153.043d4b60@127.0.0.1>
 <3FBAFAE3.2030001@adacel.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>

In face-to-face discussions at IETF#58, I learned the concern
was more about the implied semantics of the "+" used in draft.
I agreed to change replace "+" with "@" in this draft to avoid
confusion with "+" other use (zeilenga-ldap-opattrs).  An
new revision will be available soon.

Kurt

At 09:08 PM 11/18/2003, Steven Legg wrote:

>In my experience, user defined object classes reference only user attributes
>and syntax schema object classes (e.g. subentry) reference mostly operational
>attributes. Separate mechanisms for requesting only the user attributes or
>only the operational attributes would not seem to achieve very much.
>
>Regards,
>Steven
>
>Kurt D. Zeilenga wrote:
>>At 02:33 PM 11/11/2003, Jim Sermersheim wrote:
>>
>>>This draft allows the search attribute selection list to be specified as all attributes allowed by a given object class.
>>>
>>>It may be useful to allow the distinction between all user attributes allowed by a given obejct class and all operational attributes allowed by a given object class.
>>
>>While that may be useful, I rather keep this mechanism a simple short hand.
>>That is, I prefer a mechanism where the input can be expanded to the output
>>list of attribute types identifiers without having to know the particulars
>>of these attribute types.
>>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-admin@ietf.org  Wed Nov 19 03:54:25 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09156
	for <ldapext-archive@lists.ietf.org>; Wed, 19 Nov 2003 03:54:25 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMO68-00047K-Bu; Wed, 19 Nov 2003 03:54:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMO5f-00046X-3v
	for ldapext@optimus.ietf.org; Wed, 19 Nov 2003 03:53:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09140
	for <ldapext@ietf.org>; Wed, 19 Nov 2003 03:53:20 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMO5a-0003Do-00
	for ldapext@ietf.org; Wed, 19 Nov 2003 03:53:31 -0500
Received: from brmea-mail-2.sun.com ([192.18.98.43])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMO5a-0003Dl-00
	for ldapext@ietf.org; Wed, 19 Nov 2003 03:53:30 -0500
Received: from odin.France.Sun.COM ([129.157.174.8])
	by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAJ8rMPh026362;
	Wed, 19 Nov 2003 01:53:22 -0700 (MST)
Received: from Sun.COM (vpn-129-156-96-182.EMEA.Sun.COM [129.156.96.182])
	by odin.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id hAJ8rCP02448;
	Wed, 19 Nov 2003 09:53:12 +0100 (MET)
Message-ID: <3FBB2F33.6080505@Sun.COM>
Date: Wed, 19 Nov 2003 09:52:03 +0100
From: Ludovic Poitou <ludovic.poitou@Sun.COM>
Organization: SUN Microsystems
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: andrews@adacel.com.au
CC: =?ISO-8859-1?Q?=27Michael_Str=F6der=27?= <michael@stroeder.com>,
        "Ldapext (E-mail)" <ldapext@ietf.org>
Subject: Re: [ldapext] draft-behera-ldap-password-policy - bind behavior when
 pwd must be changed
References: <029f01c3ae1a$858403b0$a618200a@mtwav.adacel.com.au>
In-Reply-To: <029f01c3ae1a$858403b0$a618200a@mtwav.adacel.com.au>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi Andrew,

Your assumptions are reasonable and similar to mines.
I will add text to the ID to remove the ambiguities.

Ludovic.

Andrew Sciberras wrote:

>Hi,
>
>  
>
>>I fully agree with John's analysis.
>>
>>    
>>
>
>Thats cool, although I think my differing opinion comes from a certain level
>of ambiguity within the draft.
>
>The decription of pwdMustChange is :
>"This attribute specifies with a value of "TRUE" that users must change
>their passwords when they first bind to the directory after a password is
>set or reset by the administrator."
>
>And pwdReset is:
>"This attribute holds a flag to indicate (when TRUE) that the password has
>been reset and therefore must be changed by the user on first
>authentication"
>
>The problems are:
>* Administrator is never defined
>* The draft never states when the pwdReset value should be set to TRUE
>* The draft doesn't account for the scenario of a reset password (ie.
>pwdReset == TRUE) being changed by an Administrator again.
>
>
>The assumptions i've taken from the draft, into my implemntation, is:
>* An administrator is anyone with the power to change the user's password,
>who isn't the user.
>* If a password, which is being governed by a pwdMustChange policy, is
>changed by my definition of an administrator then the pwdReset value will be
>set to TRUE.
>* If an administrator change dthe password again, the pwdReset value will
>still be TRUE.
>
>
>My implementation was based on my assumptions. And im my implementation, the
>only way your going to get rid of that pwdReset value of TRUE is for the
>user to change the password themselves, which requires a bind operation.
>
>The only way that I can see your proposed solution working is if you and
>other implementations have made different assumptions as to what an
>administrator  is.
>If this is the case, then I think we should aim to remove this level of
>ambiguity from the draft.
>
>Catch,
>Andrew Sciberras.
>
>  
>
>>Ciao, Michael.
>>    
>>
>
>
>
>_______________________________________________
>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-admin@ietf.org  Wed Nov 19 03:59:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09237
	for <ldapext-archive@lists.ietf.org>; Wed, 19 Nov 2003 03:59:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMOAw-0004Kn-PV; Wed, 19 Nov 2003 03:59:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMOAG-0004I5-HC
	for ldapext@optimus.ietf.org; Wed, 19 Nov 2003 03:58:20 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09218
	for <ldapext@ietf.org>; Wed, 19 Nov 2003 03:58:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMOAD-0003Fx-00
	for ldapext@ietf.org; Wed, 19 Nov 2003 03:58:17 -0500
Received: from pinguin13.kwc.at ([193.228.81.158] helo=mail.hello-penguin.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMOAC-0003Fo-00
	for ldapext@ietf.org; Wed, 19 Nov 2003 03:58:17 -0500
Received: from dejan by mail.hello-penguin.com with local (Exim 3.33 #3)
	id 1AMO9b-00041A-00; Wed, 19 Nov 2003 09:57:39 +0100
Date: Wed, 19 Nov 2003 09:57:39 +0100
From: Dejan Muhamedagic <dejan@hello-penguin.com>
To: Andrew Sciberras <andrews@adacel.com.au>
Cc: "'Michael Str?der'" <michael@stroeder.com>,
        "Ldapext (E-mail)" <ldapext@ietf.org>
Subject: Re: [ldapext] draft-behera-ldap-password-policy - bind behavior when pwd must be changed
Message-ID: <20031119095738.A15337@smp.colors.kwc>
Reply-To: Dejan Muhamedagic <dejan@hello-penguin.com>
References: <3FBA0705.2@stroeder.com> <029f01c3ae1a$858403b0$a618200a@mtwav.adacel.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <029f01c3ae1a$858403b0$a618200a@mtwav.adacel.com.au>
User-Agent: Mutt/1.3.23i
X-Lotto: Suggested Lotto numbers (Austrian 6 out of 45): 4 13 25 27 41 44
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	smp.colors.kwc
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>

Hello,

Perhaps I'm missing something, but this discussion doesn't make
much sense to me.

As Andrew pointed out several times: in order to change the
password user _must_ first bind to the LDAP server.  If an LDAP
authentication client doesn't support password policy controls
that's another matter and I don't see what can the LDAP server do
about it.  That is, unless we first change semantics of the
password change operation and introduce the "password must be
changed first" return code.  Right?

Cheers,

Dejan

On Wed, Nov 19, 2003 at 08:25:41AM +1100, Andrew Sciberras wrote:
> 
> Hi,
> 
> >
> >I fully agree with John's analysis.
> >
> 
> Thats cool, although I think my differing opinion comes from a certain level
> of ambiguity within the draft.
> 
> The decription of pwdMustChange is :
> "This attribute specifies with a value of "TRUE" that users must change
> their passwords when they first bind to the directory after a password is
> set or reset by the administrator."
> 
> And pwdReset is:
> "This attribute holds a flag to indicate (when TRUE) that the password has
> been reset and therefore must be changed by the user on first
> authentication"
> 
> The problems are:
> * Administrator is never defined
> * The draft never states when the pwdReset value should be set to TRUE
> * The draft doesn't account for the scenario of a reset password (ie.
> pwdReset == TRUE) being changed by an Administrator again.
> 
> 
> The assumptions i've taken from the draft, into my implemntation, is:
> * An administrator is anyone with the power to change the user's password,
> who isn't the user.
> * If a password, which is being governed by a pwdMustChange policy, is
> changed by my definition of an administrator then the pwdReset value will be
> set to TRUE.
> * If an administrator change dthe password again, the pwdReset value will
> still be TRUE.
> 
> 
> My implementation was based on my assumptions. And im my implementation, the
> only way your going to get rid of that pwdReset value of TRUE is for the
> user to change the password themselves, which requires a bind operation.
> 
> The only way that I can see your proposed solution working is if you and
> other implementations have made different assumptions as to what an
> administrator  is.
> If this is the case, then I think we should aim to remove this level of
> ambiguity from the draft.
> 
> Catch,
> Andrew Sciberras.
> 
> >Ciao, Michael.
> 
> 
> 
> _______________________________________________
> 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-admin@ietf.org  Wed Nov 19 07:51:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14747
	for <ldapext-archive@lists.ietf.org>; Wed, 19 Nov 2003 07:51:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMRnR-0006iw-Ov; Wed, 19 Nov 2003 07:51:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMRmR-0006hr-5Z
	for ldapext@optimus.ietf.org; Wed, 19 Nov 2003 07:50:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14705
	for <ldapext@ietf.org>; Wed, 19 Nov 2003 07:49:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMRmQ-0006Ny-00
	for ldapext@ietf.org; Wed, 19 Nov 2003 07:49:58 -0500
Received: from ahmler5.mail.eds.com ([192.85.154.70])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMRmP-0006Nf-00
	for ldapext@ietf.org; Wed, 19 Nov 2003 07:49:57 -0500
Received: from ahmlir5.mail.eds.com (ahmlir5-2.mail.eds.com [192.85.154.135])
	by ahmler5.mail.eds.com (8.12.10/8.12.9) with ESMTP id hAJCnMui001423;
	Wed, 19 Nov 2003 07:49:23 -0500
Received: from ahmlir5.mail.eds.com (localhost [127.0.0.1])
	by ahmlir5.mail.eds.com (8.11.6p3/8.11.6) with ESMTP id hAJCnMm07454;
	Wed, 19 Nov 2003 07:49:22 -0500
Received: from usahm101.exmi01.exch.eds.com (usahm101.exmi01.exch.eds.com [207.37.138.189])
	by ahmlir5.mail.eds.com (8.11.6p3/8.11.6) with ESMTP id hAJCnMi07448;
	Wed, 19 Nov 2003 07:49:22 -0500
Received: by usahm101.exmi01.exch.eds.com with Internet Mail Service (5.5.2657.72)
	id <WADNPH0B>; Wed, 19 Nov 2003 07:49:23 -0500
Message-ID: <7A62AD36B644D411B0E500508BDF0CEC188D6704@usahm016.exmi01.exch.eds.com>
From: "O'Neill, Mark E" <mark.oneill@eds.com>
To: =?iso-8859-1?Q?=27Michael_Str=F6der=27?= <michael@stroeder.com>
Cc: "Ldapext (E-mail)" <ldapext@ietf.org>
Subject: RE: [ldapext] draft-behera-ldap-password-policy - bind behavior w
	hen pwd must be changed
Date: Wed, 19 Nov 2003 07:49:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Hi,

This is an excellent discussion but I would like to add one thought
regarding the pwdReset attribute.

In most organisations I have worked with, there is a security =
requirement
that has always proven difficult to implement:=20

	"A user should be suspended if they do not change their password
within N days of an administrative reset."

I have normally got round this by defining an attribute similar to =
pwdReset
but placing a date in the attribute rather than simply making it =
Boolean.
But this requires some knowledge of whether or not the user has =
subsequently
changed their password.

I agree with Andrew's interpretation of Administrator as this must not =
be
intended to mean "directory manager".

Mark

-----Original Message-----
From: Andrew Sciberras [mailto:andrews@adacel.com.au]=20
Sent: Tuesday, November 18, 2003 4:26 PM
To: 'Michael Str=F6der'
Cc: Ldapext (E-mail)
Subject: RE: [ldapext] draft-behera-ldap-password-policy - bind =
behavior
when pwd must be changed


Hi,

>
>I fully agree with John's analysis.
>

Thats cool, although I think my differing opinion comes from a certain =
level
of ambiguity within the draft.

The decription of pwdMustChange is :
"This attribute specifies with a value of "TRUE" that users must change
their passwords when they first bind to the directory after a password =
is
set or reset by the administrator."

And pwdReset is:
"This attribute holds a flag to indicate (when TRUE) that the password =
has
been reset and therefore must be changed by the user on first
authentication"

The problems are:
* Administrator is never defined
* The draft never states when the pwdReset value should be set to TRUE
* The draft doesn't account for the scenario of a reset password (ie.
pwdReset =3D=3D TRUE) being changed by an Administrator again.


The assumptions i've taken from the draft, into my implemntation, is:
* An administrator is anyone with the power to change the user's =
password,
who isn't the user.
* If a password, which is being governed by a pwdMustChange policy, is
changed by my definition of an administrator then the pwdReset value =
will be
set to TRUE.
* If an administrator change dthe password again, the pwdReset value =
will
still be TRUE.


My implementation was based on my assumptions. And im my =
implementation, the
only way your going to get rid of that pwdReset value of TRUE is for =
the
user to change the password themselves, which requires a bind =
operation.

The only way that I can see your proposed solution working is if you =
and
other implementations have made different assumptions as to what an
administrator  is.
If this is the case, then I think we should aim to remove this level of
ambiguity from the draft.

Catch,
Andrew Sciberras.

>Ciao, Michael.



_______________________________________________
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-admin@ietf.org  Wed Nov 19 09:15:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17306
	for <ldapext-archive@lists.ietf.org>; Wed, 19 Nov 2003 09:15:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMT6j-0003RX-JA; Wed, 19 Nov 2003 09:15:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMT62-0003Oq-Qs
	for ldapext@optimus.ietf.org; Wed, 19 Nov 2003 09:14:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17253
	for <ldapext@ietf.org>; Wed, 19 Nov 2003 09:14:05 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMT61-0007ZP-00
	for ldapext@ietf.org; Wed, 19 Nov 2003 09:14:17 -0500
Received: from e4.ny.us.ibm.com ([32.97.182.104])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMT60-0007YZ-00
	for ldapext@ietf.org; Wed, 19 Nov 2003 09:14:16 -0500
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hAJEDihn042318
	for <ldapext@ietf.org>; Wed, 19 Nov 2003 09:13:44 -0500
Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAJEDhQG205134
	for <ldapext@ietf.org>; Wed, 19 Nov 2003 09:13:43 -0500
Subject: RE: [ldapext] draft-behera-ldap-password-policy - bind behavior when pwd
 must be changed
To: ldapext@ietf.org
X-Mailer: Lotus Notes Release 5.0.12   February 13, 2003
Message-ID: <OFA30AF1A5.73BC39EB-ON86256DE3.004C2CC0-86256DE3.004E28E1@us.ibm.com>
From: John McMeeking <jmcmeek@us.ibm.com>
Date: Wed, 19 Nov 2003 08:13:42 -0600
X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.5|September 18, 2003) at
 11/19/2003 08:13:43 AM
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable





Andrew,

I agree with your analysis up to the point where the user must change h=
is
password=2E

If the client is password policy aware (i=2Ee=2E it includes the passwo=
rd
policy request control on bind and other requests), the client can bind=
 to
the server with a password that must be reset=2E  The bind should be
successful, and the password policy response control will indicate that=
 the
password must be changed=2E  The client can then issue a modify request=
 or
the "password modify" extended operation (RFC 3062)=2E

This requires that the user have access to a password policy aware
application to change his password after it has been reset=2E

But your note did get me thinking a bit more=2E  Many times a password =
change
is not done by a client authenticated as the user=2E  In fact, the user=
 may
not even have authority to change his password directly, or any other
information=2E  Instead, it is done through an application running unde=
r some
other identity=2E  So maybe this flag should be reset by any successful=

request to change the password that includes both the user's old passwo=
rd
and the new password=2E  And I could see a strong desire for an adminis=
trator
be able to clear this flag - but maybe that should be left to an
implementation=2E

What I feel is lacking in the draft is the distinction between a client=

that provides the password policy request control and a client that doe=
s
not=2E
- If no password policy control is present, a bind with a reset passwor=
d
should fail
- If a password policy is present, a bind with a reset password should
succeed with a reponse control returned as is currently stated in the
draft=2E

And I'll add your desire to see clarification as to when the "password
reset indicator" should be set to FALSE=2E


John  McMeeking



                                                                       =
                                             
                      "Andrew                                          =
                                             
                      Sciberras"               To:       "'Michael Str=F6=
der'" <michael@stroeder=2Ecom>                 
                      <andrews@adacel=2Ec        cc:       "Ldapext \(E=
-mail\)" <ldapext@ietf=2Eorg>                    
                      om=2Eau>                   Subject:  RE: [ldapext=
] draft-behera-ldap-password-policy - bind     
                      Sent by:                  behavior when pwd must =
be changed                                   
                      ldapext-admin@iet                                =
                                             
                      f=2Eorg                                          =
                                               
                                                                       =
                                             
                                                                       =
                                             
                      11/18/2003 03:25                                 =
                                             
                      PM                                               =
                                             
                      Please respond to                                =
                                             
                      andrews                                          =
                                             
                                                                       =
                                             
                                                                       =
                                             





Hi,

>
>I fully agree with John's analysis=2E
>

Thats cool, although I think my differing opinion comes from a certain
level
of ambiguity within the draft=2E

The decription of pwdMustChange is :
"This attribute specifies with a value of "TRUE" that users must change=

their passwords when they first bind to the directory after a password =
is
set or reset by the administrator=2E"

And pwdReset is:
"This attribute holds a flag to indicate (when TRUE) that the password =
has
been reset and therefore must be changed by the user on first
authentication"

The problems are:
* Administrator is never defined
* The draft never states when the pwdReset value should be set to TRUE
* The draft doesn't account for the scenario of a reset password (ie=2E=

pwdReset =3D=3D TRUE) being changed by an Administrator again=2E


The assumptions i've taken from the draft, into my implemntation, is:
* An administrator is anyone with the power to change the user's passwo=
rd,
who isn't the user=2E
* If a password, which is being governed by a pwdMustChange policy, is
changed by my definition of an administrator then the pwdReset value wi=
ll
be
set to TRUE=2E
* If an administrator change dthe password again, the pwdReset value wi=
ll
still be TRUE=2E


My implementation was based on my assumptions=2E And im my implementati=
on,
the
only way your going to get rid of that pwdReset value of TRUE is for th=
e
user to change the password themselves, which requires a bind operation=
=2E

The only way that I can see your proposed solution working is if you an=
d
other implementations have made different assumptions as to what an
administrator  is=2E
If this is the case, then I think we should aim to remove this level of=

ambiguity from the draft=2E

Catch,
Andrew Sciberras=2E

>Ciao, Michael=2E



_______________________________________________
Ldapext mailing list
Ldapext@ietf=2Eorg
https://www1=2Eietf=2Eorg/mailman/listinfo/ldapext

=



_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Wed Nov 19 10:03:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19344
	for <ldapext-archive@lists.ietf.org>; Wed, 19 Nov 2003 10:03:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMTrB-0007SB-GC; Wed, 19 Nov 2003 10:03:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMTqH-0007Gk-HS
	for ldapext@optimus.ietf.org; Wed, 19 Nov 2003 10:02:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19186
	for <ldapext@ietf.org>; Wed, 19 Nov 2003 10:01:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMTqF-0000Zj-00
	for ldapext@ietf.org; Wed, 19 Nov 2003 10:02:03 -0500
Received: from pinguin13.kwc.at ([193.228.81.158] helo=mail.hello-penguin.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMTqE-0000Zc-00
	for ldapext@ietf.org; Wed, 19 Nov 2003 10:02:03 -0500
Received: from dejan by mail.hello-penguin.com with local (Exim 3.33 #3)
	id 1AMToZ-0004it-00; Wed, 19 Nov 2003 16:00:19 +0100
Date: Wed, 19 Nov 2003 16:00:19 +0100
From: Dejan Muhamedagic <dejan@hello-penguin.com>
To: John McMeeking <jmcmeek@us.ibm.com>
Cc: ldapext@ietf.org
Subject: Re: [ldapext] draft-behera-ldap-password-policy - bind behavior when pwd must be changed
Message-ID: <20031119160019.A18078@smp.colors.kwc>
Reply-To: Dejan Muhamedagic <dejan@hello-penguin.com>
References: <OFA30AF1A5.73BC39EB-ON86256DE3.004C2CC0-86256DE3.004E28E1@us.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <OFA30AF1A5.73BC39EB-ON86256DE3.004C2CC0-86256DE3.004E28E1@us.ibm.com>
User-Agent: Mutt/1.3.23i
X-Lotto: Suggested Lotto numbers (Austrian 6 out of 45): 3 4 13 21 23 26
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	smp.colors.kwc
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>

John,

On Wed, Nov 19, 2003 at 08:13:42AM -0600, John McMeeking wrote:
> 
[snip]
>
> What I feel is lacking in the draft is the distinction between a client
> that provides the password policy request control and a client that does
> not.
> - If no password policy control is present, a bind with a reset password
> should fail
> - If a password policy is present, a bind with a reset password should
> succeed with a reponse control returned as is currently stated in the
> draft.

How can LDAP server tell if the client supports password policy or
not?  All it knows is that they want to bind.

I agree that the security policy should be enforced at the server
and not at the client, but in this case we have no means to do
that without "breaking" clients which don't know how to read the
policy.

Cheers,

Dejan

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Wed Nov 19 10:33:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22085
	for <ldapext-archive@lists.ietf.org>; Wed, 19 Nov 2003 10:33:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMUKD-0001VR-61; Wed, 19 Nov 2003 10:33:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMUJY-0001Us-P3
	for ldapext@optimus.ietf.org; Wed, 19 Nov 2003 10:32:21 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21981
	for <ldapext@ietf.org>; Wed, 19 Nov 2003 10:32:06 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMUJW-0001CQ-00
	for ldapext@ietf.org; Wed, 19 Nov 2003 10:32:18 -0500
Received: from goliath.siemens.de ([192.35.17.28])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMUJV-0001CJ-00
	for ldapext@ietf.org; Wed, 19 Nov 2003 10:32:17 -0500
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14])
	by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hAJFWBV24992;
	Wed, 19 Nov 2003 16:32:11 +0100 (MET)
Received: from pappel.asw.mchp.siemens.de ([139.25.160.30])
	by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id hAJFWBF06626;
	Wed, 19 Nov 2003 16:32:11 +0100 (MET)
Received: by pappel.asw.mchp.siemens.de with Internet Mail Service (5.5.2657.72)
	id <V9874RA0>; Wed, 19 Nov 2003 16:32:10 +0100
Message-ID: <D1533D42A5A9D511A8090050DA3D8357844390@pappel.asw.mchp.siemens.de>
From: "Volpers, Helmut" <helmut.volpers@siemens.com>
To: "'Dejan Muhamedagic'" <dejan@hello-penguin.com>,
        John McMeeking
	 <jmcmeek@us.ibm.com>
Cc: ldapext@ietf.org
Subject: RE: [ldapext] draft-behera-ldap-password-policy - bind behavior w
	hen pwd must be changed
Date: Wed, 19 Nov 2003 16:32:09 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>

Hi,

I agree with John. The draft should distinguish between clients which
provides the password policy request control and clients which don't support
this.

other comments inline.

> -----Original Message-----
> From: Dejan Muhamedagic [mailto:dejan@hello-penguin.com] 
> Sent: Wednesday, November 19, 2003 4:00 PM
> To: John McMeeking
> Cc: ldapext@ietf.org
> Subject: Re: [ldapext] draft-behera-ldap-password-policy - 
> bind behavior when pwd must be changed
> 
> 
> John,
> 
> On Wed, Nov 19, 2003 at 08:13:42AM -0600, John McMeeking wrote:
> > 
> [snip]
> >
> > What I feel is lacking in the draft is the distinction between a 
> > client that provides the password policy request control 
> and a client 
> > that does not.
> > - If no password policy control is present, a bind with a reset 
> > password should fail
> > - If a password policy is present, a bind with a reset 
> password should 
> > succeed with a reponse control returned as is currently 
> stated in the 
> > draft.
> 
> How can LDAP server tell if the client supports password 
> policy or not?  All it knows is that they want to bind.
> 
> I agree that the security policy should be enforced at the 
> server and not at the client, but in this case we have no 
> means to do that without "breaking" clients which don't know 
> how to read the policy.

the LDAPserver can publish the control in the ROOT by supported controls.
the Ldapclient should not read the Password policy.

Helmut

> 
> Cheers,
> 
> Dejan
> 
> _______________________________________________
> 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-admin@ietf.org  Wed Nov 19 17:24:25 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18476
	for <ldapext-archive@lists.ietf.org>; Wed, 19 Nov 2003 17:24:25 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMajx-0003Jb-5J; Wed, 19 Nov 2003 17:24:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMajS-0003I1-Tf
	for ldapext@optimus.ietf.org; Wed, 19 Nov 2003 17:23:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18439
	for <ldapext@ietf.org>; Wed, 19 Nov 2003 17:23:15 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMajP-0004jv-00
	for ldapext@ietf.org; Wed, 19 Nov 2003 17:23:27 -0500
Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMajN-0004je-00
	for ldapext@ietf.org; Wed, 19 Nov 2003 17:23:25 -0500
Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16)
	id <B0001a7eb0>; Thu, 20 Nov 2003 09:15:46 +1100
Received: (qmail 29040 invoked from network); 19 Nov 2003 22:22:52 -0000
Received: from unknown (HELO shylock) (10.32.24.166)
  by nexus.adacel.com with SMTP; 19 Nov 2003 22:22:52 -0000
Reply-To: <andrews@adacel.com.au>
From: "Andrew Sciberras" <andrews@adacel.com.au>
To: "'Volpers, Helmut'" <helmut.volpers@siemens.com>
Cc: "Ldapext \(E-mail\)" <ldapext@ietf.org>,
        "'John McMeeking'" <jmcmeek@us.ibm.com>
Subject: RE: [ldapext] draft-behera-ldap-password-policy - bind behaviour when pwd must be changed
Date: Thu, 20 Nov 2003 09:22:53 +1100
Message-ID: <032f01c3aeeb$adab2d10$a618200a@mtwav.adacel.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <D1533D42A5A9D511A8090050DA3D8357844390@pappel.asw.mchp.siemens.de>
Content-Transfer-Encoding: 7bit
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Hi,


>-----Original Message-----
>From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org]On Behalf Of
Volpers, Helmut
>Sent: Thursday, 20 November 2003 2:32
>
>Hi,
>
>I agree with John. The draft should distinguish between clients which
>provides the password policy request control and clients which
>don't support
>this.


Generally I agree with this point. I think it is sensible, as a security
precaution, to fail binds if the directory cannot be certain that the client
would understand the scope in which it is allowing the bind to proceed.
Compare operations should fail aswell.

In principal, I think that any client that cannot handle a password policy
response control should not be interacting with a password policy enabled
directory.
If the client is unable to interpret the contents of the control, they've
got a lot more than the changeAfterReset dilemma to worry about. Each of the
errors and warnings
	* timeBeforeExpiration,
	* graceLoginsRemaining,
	* passwordExpired,
	* acocuntLocked,
	* changeAfterReset,
	* passwordModNotAllowed,
	* mustSupplyOldPassword,
	* invalidPasswordSyntax,
	* passwordTooShort,
	* passwordTooYoung,
	* passwordInHistory
provide vital information as to why the directory is not ( or will not in
the future) be behaving according to the "normal" LDAP protocol rules.
It is simply pointless enforcing a password policy and having unaware
clients interacting with the system.


My overall view is that the server must fail binds and compares if pwdReset
is true and it does not think that the client could handle a response
control. (Still not sure about the search operation. Any suggestions ???).
It must handle binds and compares normally if the client has indicated that
they are able to handle a response control.
This requires a few changes to be made:
* Clear statement that clients MUST provide a request control if they want
the password policy to apply normally
* Clear statement that the server will be basing its opinion on whether a
client supports the password policy on whether the client has provided a
request control.
* Mandating that the server must return a response control (in an erroneous
or warning situation) when the client has sent one



Cheers,
Andrew Sciberras.

P.S.
Please let me know if a new version of this draft is due to be made, I have
some other suggestions that I'd like to make. Thanks.



_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Thu Nov 20 04:44:28 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26835
	for <ldapext-archive@lists.ietf.org>; Thu, 20 Nov 2003 04:44:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMlM6-000575-JW; Thu, 20 Nov 2003 04:44:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMlLw-000566-SK
	for ldapext@optimus.ietf.org; Thu, 20 Nov 2003 04:43:57 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26793
	for <ldapext@ietf.org>; Thu, 20 Nov 2003 04:43:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMlLu-0007Xu-00
	for ldapext@ietf.org; Thu, 20 Nov 2003 04:43:54 -0500
Received: from brmea-mail-2.sun.com ([192.18.98.43])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMlLu-0007Xr-00
	for ldapext@ietf.org; Thu, 20 Nov 2003 04:43:54 -0500
Received: from odin.France.Sun.COM ([129.157.174.8])
	by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAK9hjPh013089;
	Thu, 20 Nov 2003 02:43:50 -0700 (MST)
Received: from Sun.COM (dhcp-gnb07-211-108 [129.157.211.108])
	by odin.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id hAK9hiP08752;
	Thu, 20 Nov 2003 10:43:44 +0100 (MET)
Message-ID: <3FBC8C8A.1040603@Sun.COM>
Date: Thu, 20 Nov 2003 10:42:34 +0100
From: Ludovic Poitou <ludovic.poitou@Sun.COM>
Organization: SUN Microsystems
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: andrews@adacel.com.au
CC: "'Volpers, Helmut'" <helmut.volpers@siemens.com>,
        "Ldapext (E-mail)" <ldapext@ietf.org>,
        "'John McMeeking'" <jmcmeek@us.ibm.com>
Subject: Re: [ldapext] draft-behera-ldap-password-policy - bind behaviour
 when pwd must be changed
References: <032f01c3aeeb$adab2d10$a618200a@mtwav.adacel.com.au>
In-Reply-To: <032f01c3aeeb$adab2d10$a618200a@mtwav.adacel.com.au>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Andrew,

I've started editing the new version of the ID. Feel free to post your 
suggestions.
One of the comments that was made to me about the draft is about error 
results returned in the control. The question was whether we should 
create new LDAP Result codes or keep these in the Password Policy 
control. I think that most of them can be considered as sub-results of 
typical LDAP results. But the recent discussion let me believe that some 
errors could be new LDAP Result code and not returned in the Control. 
Still needs full analysis though.

Ludovic.

Andrew Sciberras wrote:

>Hi,
>
>
>  
>
>>-----Original Message-----
>>From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org]On Behalf Of
>>    
>>
>Volpers, Helmut
>  
>
>>Sent: Thursday, 20 November 2003 2:32
>>
>>Hi,
>>
>>I agree with John. The draft should distinguish between clients which
>>provides the password policy request control and clients which
>>don't support
>>this.
>>    
>>
>
>
>Generally I agree with this point. I think it is sensible, as a security
>precaution, to fail binds if the directory cannot be certain that the client
>would understand the scope in which it is allowing the bind to proceed.
>Compare operations should fail aswell.
>
>In principal, I think that any client that cannot handle a password policy
>response control should not be interacting with a password policy enabled
>directory.
>If the client is unable to interpret the contents of the control, they've
>got a lot more than the changeAfterReset dilemma to worry about. Each of the
>errors and warnings
>	* timeBeforeExpiration,
>	* graceLoginsRemaining,
>	* passwordExpired,
>	* acocuntLocked,
>	* changeAfterReset,
>	* passwordModNotAllowed,
>	* mustSupplyOldPassword,
>	* invalidPasswordSyntax,
>	* passwordTooShort,
>	* passwordTooYoung,
>	* passwordInHistory
>provide vital information as to why the directory is not ( or will not in
>the future) be behaving according to the "normal" LDAP protocol rules.
>It is simply pointless enforcing a password policy and having unaware
>clients interacting with the system.
>
>
>My overall view is that the server must fail binds and compares if pwdReset
>is true and it does not think that the client could handle a response
>control. (Still not sure about the search operation. Any suggestions ???).
>It must handle binds and compares normally if the client has indicated that
>they are able to handle a response control.
>This requires a few changes to be made:
>* Clear statement that clients MUST provide a request control if they want
>the password policy to apply normally
>* Clear statement that the server will be basing its opinion on whether a
>client supports the password policy on whether the client has provided a
>request control.
>* Mandating that the server must return a response control (in an erroneous
>or warning situation) when the client has sent one
>
>
>
>Cheers,
>Andrew Sciberras.
>
>P.S.
>Please let me know if a new version of this draft is due to be made, I have
>some other suggestions that I'd like to make. Thanks.
>
>
>
>_______________________________________________
>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-admin@ietf.org  Thu Nov 20 07:17:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01089
	for <ldapext-archive@lists.ietf.org>; Thu, 20 Nov 2003 07:17:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMnk4-0004IR-Sw; Thu, 20 Nov 2003 07:17:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMnjA-0004HN-88
	for ldapext@optimus.ietf.org; Thu, 20 Nov 2003 07:16:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01069
	for <ldapext@ietf.org>; Thu, 20 Nov 2003 07:15:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMnj9-0001iu-00
	for ldapext@ietf.org; Thu, 20 Nov 2003 07:16:03 -0500
Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMnj8-0001iP-00
	for ldapext@ietf.org; Thu, 20 Nov 2003 07:16:02 -0500
Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16)
	id <B0001a8a42>; Thu, 20 Nov 2003 23:08:19 +1100
Received: (qmail 23440 invoked from network); 20 Nov 2003 12:15:30 -0000
Received: from unknown (HELO shylock) (10.32.24.166)
  by nexus.adacel.com with SMTP; 20 Nov 2003 12:15:30 -0000
Reply-To: <andrews@adacel.com.au>
From: "Andrew Sciberras" <andrews@adacel.com.au>
To: "Ldapext \(E-mail\)" <ldapext@ietf.org>
Date: Thu, 20 Nov 2003 23:15:27 +1100
Message-ID: <000e01c3af5f$fc853c90$a618200a@mtwav.adacel.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [ldapext] Various Password Policy Comments
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi!

Here are some concerns that I have about the password policy draft.
Many of these have been sent to some of the draft authors, but I don't
believe they ever made it to this mailing list.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*Section 4.2.*
Shouldn't these operation attribute's have:

USAGE directoryOperation

aswell?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*Section 4.3.4, 4.3.5, 4.3.7.

Chances are low, but what do I do if the Expiration is Warned, I have
failures, or use grace logins multiple times within one generalizedTime
period?

It is illegal for me to store two values with the same value.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*Section 4.3. Attribute Types for Password Policy State Information.

In this section the attributes pwdChangeTime, pwdAccountLockedTime,
pwdExpirationWarned, pwdReset and pwdPolicySubentry are all defined as being
SINGLE-VALUE.
Obviously this is correct, since there will only be one value for the state
attribute for each password attribute that the policy applies to.
However, we have chosen to implement our solution according to the
"Proposed Draft Amendments for Maximising Alignment between X.500 and LDAP"
(http://www.openldap.org/lists/ietf-ldapbis/200305/msg00024.html)

The SINGLE VALUE'dness of these attributes presents difficulties when
representing
these attributes in X.500. If the password policy applies to multiple
attributes,
our X.500 representation of the attribute will contain multiple values.
For this reason we have chosen not to include the SINGLE-VALUE
characteristic in
our implementation.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*Section 4.3.1 - Password Policy State Attribute Option
"Since the password policy could apply to several attributes used to
 store passwords, each of the above operational attributes must have
 an option to specify which pwdAttribute is applies to."

Just a typo... "is" (third last word) should probably be "it".


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*Section 4.3.2 - pwdAccountLockedTime
"A 0 value means that the account has been locked permanently,
 and that only an administrator can unlock the account."

It is unclear as to what a zero (0) value GeneralizedTime is. In our
implementation it has been assumed that this is the smallest legal
GeneralizedTime (00000101000Z).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*Section 5.2 Response Control.
The following is the ASN.1 of the Response Control as defined in the draft:
PasswordPolicyResponseValue ::= SEQUENCE {
      warning   [0] CHOICE OPTIONAL {
         timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
         graceLoginsRemaining  [1] INTEGER (0 .. maxInt) }
      error     [1] ENUMERATED OPTIONAL {
         passwordExpired       (0),
         accountLocked         (1),
         changeAfterReset      (2),
         passwordModNotAllowed (3),
         mustSupplyOldPassword (4),
         invalidPasswordSyntax (5),
         passwordTooShort      (6),
         passwordTooYoung      (7),
         passwordInHistory     (8) } }

We have changed this to look like the one below.
The changes are adding a comma after the warning CHOICE, and putting the
OPTIONAL at the end of the braces.
PasswordPolicyResponseValue ::= SEQUENCE {
      warning   [0] CHOICE {
         timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
         graceLoginsRemaining  [1] INTEGER (0 .. maxInt) } OPTIONAL,
      error     [1] ENUMERATED {
         passwordExpired       (0),
         accountLocked         (1),
         changeAfterReset      (2),
         passwordModNotAllowed (3),
         mustSupplyOldPassword (4),
         invalidPasswordSyntax (5),
         passwordTooShort      (6),
         passwordTooYoung      (7),
         passwordInHistory     (8) } OPTIONAL }


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*Section 6.1.1 Bind Operation - Check for a locked account.
"If the value of the pwdAccountLockedTime attribute is 0, or if
 the current time is less than the value of the
 pwdAccountLockedTime attribute added to the value of the
 pwdLockoutDuration, the account is locked."

Once again, the value of zero (0) is assumed to be 0000010100Z.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Section 6.1.2D (Page 19)
>If the pwdExpirationWarned attribute is present and has a
>time value, the warning time is the value of the
>pwdExpirationWarned attribute plus the value of the
>pwdExpireWarning attribute minus the current time.

WarningTime = pwdExpirationWarned + pwdExpireWarning - Current Time

>If the pwdExpirationWarned attribute is not present, the
>server MUST subtract the current time from the time stored
>in pwdChangedTime to arrive at the password's age. If the
>age is greater than the value of the pwdMaxAge attribute
>minus the value of the pwdExpireWarning attribute, the
>server MUST set the current time as the value of the
>pwdExpirationWarned attribute, and the warning time is the
>value of pwdMaxAge minus the password's age.

PasswordAge = pwdChangeTime - CurrentTime
WarningTime = pwdMaxAge - PasswordAge

Firstly, I believe that the calculation of the PasswordAge is incorrect.
I think that the pwdChangeTime should be subtracted from the current time.

Following the warning time calculation steps described in the draft can also
lead to misleading results.
The example below will illustrate a scenario where this is the case.

pwdMaxAge = 100 seconds.
pwdExpireWarning = 50 seconds.
The user binds when the password is 80 seconds old.
PasswordAge = 80.
WarningTime = (pwdMaxAge - PasswordAge) = 20 seconds.
At this stage the user has been told that their password will expire in 20
seconds.

User binds again in 5 seconds time. (I.e. PasswordAge = 85 seconds).
Since the pwdExpirationWarned is now present we calculate the warning time
differently.

WarningTime = (pwdExpirationWarned + pwdExpireWarning - CurrentTime)
  = (pwdExpirationWarned - CurrentTime) + pwdExpireWarning
  = (-5) + 50
  = 45
The user is now told that their password will expire in 45 seconds.
Our implementation of the password policy will simply return
pwdExpireWarning as the first warning time value.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Section 6.1.2B (Page 20)
>If the number of these failures is greater or equal to the
>pwdMaxFailure attribute, the server MUST lock the account
>by setting the value of the pwdAccountLockedTime attribute
>to the current time. After locking the account, the server
>MUST send a bindResponse to the client with the
>resultCode: unwillingToPerform (53), and MUST include the
>passwordPolicyResponse in the controls field of the
>bindResponse message with the error: accountLocked (1).

I do not think that the return code should be unwillingToPerform. In this
scenario, the user has got their password wrong and this incorrect attempt
has made the number of failures exceed the pwdMaxFailure limit. In this case
the reason why the operation (BIND) is going to fail is because of the
incorrect password. The fact that the number of bind failures has exceeded a
policy limit is just a consequence of that.
For this reason I believe that the resultCode should be invalidCredentials.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*Section 6.2.(1&2) Modify Password Operation.
Just a personal opinion, I think that the pwdMustChange setting should take
precedence over the pwdSafeModify one. I therefore think that it would
probably make more sense to swap steps one and two around. From an
implementation point of view I also feel that it is easier and quicker to
make the pwdMustChange check over the pwdSafeModify one. This will result in
the DSA performing less operations to determine that the user has broken a
policy rule.

I also think that it should be stated that if the password is being modified
by an administrator the pwdSafeModify policy rule should be ignored.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*Section 6.2.9
The pwdReset attribute should not be removed if an Administrator has
modified the Password value.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*Section 6.3.2B
>If the server is unable to check the length (due to a hashed
>password or otherwise), the value of pwdCheckSyntax MUST be
>evaluated. If the value is 1, operation MUST continue. If the
>value is 2, the server MUST send an addResponse to the client
>with the resultCode: constraintViolation (19), and MUST
>include the passwordPolicyResponse in the controls field of
>the addResponse message with the error: passwordTooShort (5).

A passwordTooShort error code here seems inappropriate. Since the server
could not determine the length due to the syntax of the password wouldn't it
be more appropriate to use a invalidPasswordSyntax error code.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Section 6.3.3
After this step there should be a step number 4. It should state that the
pwdReset attribute MUST be set to true.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*Section 6.4.2A
Since we have had a successful compare, I believe that the
pwdAccountLockedTime should be removed at this stage as well.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Section 6.4.2C
I believe that the Warning Time calculations here should be amended to my
recommendations of section 6.1.2D.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

*Section 6.4.2D
>If the result of the compare operation is false, the server MUST
>do the following:
 <snip>
>D. If no errors were returned, the server MUST send a
>compareResponse with the resultCode: compareTrue (6), and
>MUST include the passwordPolicyResponse with nothing in
>the SEQUENCE.
Section D above is related to the fact that the compare was false. The
server should therefore return compareFalse.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*Section 7.5 Other Operations
>For operations other than bind, unbind, abandon, search or StartTLS,
>the client MUST check the following result code and control to
>determine if the user needs to change the password immediately.

I don't think that a search operation should be permitted if the user must
change their password now.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*Section 8 - Administration of a Password Policy
I think a value for the administrativeRole operational attribute
(as defined in
http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-subentry-07.txt)
should be specified for the password policy subentry.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Just a note for developers of X.500/LDAP directories which come from an
X.500 background:
A portion of the pwdHistory value contains the string representation of the
dotted-decimal
OID that defines the syntax used to store the password.
Not all X.500 syntax's have an LDAP specific encoding or a syntax OID, which
make pwdHistory
maintenance impossible.



Cheers,
Andrew Sciberras
Adacel Technologies

P.S.
Jim, thanks for providing me with these concerns after I had lost them.


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Thu Nov 20 13:53:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18421
	for <ldapext-archive@lists.ietf.org>; Thu, 20 Nov 2003 13:53:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMtvI-0000vz-Qr; Thu, 20 Nov 2003 13:53:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMtui-0000vN-3o
	for ldapext@optimus.ietf.org; Thu, 20 Nov 2003 13:52:24 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18368
	for <ldapext@ietf.org>; Thu, 20 Nov 2003 13:52:10 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMtuf-0000KX-00
	for ldapext@ietf.org; Thu, 20 Nov 2003 13:52:21 -0500
Received: from krl9-d9bb4179.pool.mediaways.net ([217.187.65.121] helo=nb2.stroeder.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMtue-0000KE-00
	for ldapext@ietf.org; Thu, 20 Nov 2003 13:52:21 -0500
Received: from localhost (localhost [127.0.0.1])
	by nb2.stroeder.com (Postfix) with ESMTP
	id A1A3F33DBC; Thu, 20 Nov 2003 19:51:41 +0100 (CET)
Received: from stroeder.com (localhost [127.0.0.1])
	by nb2.stroeder.com (Postfix) with ESMTP
	id 5175833D86; Thu, 20 Nov 2003 19:51:40 +0100 (CET)
Message-ID: <3FBD0D3B.1030901@stroeder.com>
Date: Thu, 20 Nov 2003 19:51:39 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: andrews@adacel.com.au
Cc: "Ldapext (E-mail)" <ldapext@ietf.org>
Subject: Re: [ldapext] draft-behera-ldap-password-policy - bind behaviour
 when pwd must be changed
References: <032f01c3aeeb$adab2d10$a618200a@mtwav.adacel.com.au>
In-Reply-To: <032f01c3aeeb$adab2d10$a618200a@mtwav.adacel.com.au>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Content-Transfer-Encoding: 7bit
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Andrew Sciberras wrote:
> 
> In principal, I think that any client that cannot handle a password policy
> response control should not be interacting with a password policy enabled
> directory.

The majority of LDAP clients cannot handle a password  policy response 
control and judging from my personal experience I wouldn't bet that this 
will change any time soon.

> If the client is unable to interpret the contents of the control, they've
> got a lot more than the changeAfterReset dilemma to worry about. Each of the
> errors and warnings
> 	* timeBeforeExpiration,
> 	* graceLoginsRemaining,
> 	* passwordExpired,
> 	* acocuntLocked,
> 	* changeAfterReset,
> 	* passwordModNotAllowed,
> 	* mustSupplyOldPassword,
> 	* invalidPasswordSyntax,
> 	* passwordTooShort,
> 	* passwordTooYoung,
> 	* passwordInHistory
> provide vital information as to why the directory is not ( or will not in
> the future) be behaving according to the "normal" LDAP protocol rules.

BindRequest should fail. That's it. Fine-grained error handling at the
client would be nice but won't be possible with the majority of LDAP
clients.

The server should provide an appropriate informational message in
LDAPResult.errorMessage though since most LDAP clients display or log this
message text. Yes, this is not perfect for client-side error handling but
it's common practice which somewhat helps in most situations.

> * Clear statement that clients MUST provide a request control if they want
> the password policy to apply normally

Are you saying here that the password policy should not be in effect if the
client does not provide a request control? Maybe I did get you wrong?

> * Clear statement that the server will be basing its opinion on whether a
> client supports the password policy on whether the client has provided a
> request control.

+1

> * Mandating that the server must return a response control (in an erroneous
> or warning situation) when the client has sent one

+1

Ciao, Michael.



_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Thu Nov 20 17:44:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04218
	for <ldapext-archive@lists.ietf.org>; Thu, 20 Nov 2003 17:44:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMxWs-0002gb-3B; Thu, 20 Nov 2003 17:44:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMxWY-0002g9-FW
	for ldapext@optimus.ietf.org; Thu, 20 Nov 2003 17:43:42 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04167
	for <ldapext@ietf.org>; Thu, 20 Nov 2003 17:43:27 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMxWV-0005hL-00
	for ldapext@ietf.org; Thu, 20 Nov 2003 17:43:40 -0500
Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMxWU-0005fa-00
	for ldapext@ietf.org; Thu, 20 Nov 2003 17:43:38 -0500
Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16)
	id <B0001a9113>; Fri, 21 Nov 2003 09:35:52 +1100
Received: (qmail 29119 invoked from network); 20 Nov 2003 22:43:06 -0000
Received: from unknown (HELO shylock) (10.32.24.166)
  by nexus.adacel.com with SMTP; 20 Nov 2003 22:43:06 -0000
Reply-To: <andrews@adacel.com.au>
From: "Andrew Sciberras" <andrews@adacel.com.au>
To: "=?iso-8859-1?Q?'Michael_Str=F6der'?=" <michael@stroeder.com>
Cc: "Ldapext \(E-mail\)" <ldapext@ietf.org>
Subject: RE: [ldapext] draft-behera-ldap-password-policy - bind behaviour when pwd must be changed
Date: Fri, 21 Nov 2003 09:43:04 +1100
Message-ID: <005601c3afb7$a9e048b0$a618200a@mtwav.adacel.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <3FBD0D3B.1030901@stroeder.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA04168
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

>Michael Str=F6der wrote:
>
>BindRequest should fail. That's it.

I really believe that the compare should fail as well.
The description for the 'Compare Operation':
"The compare operation MAY be used to compare a password. This might
 be performed when a client wishes to verify that user's supplied
 password is correct. An example of this is an LDAP HTTP
 authentication redirector. It may be desirable to use this rather
 than performing a bind operation in order to reduce possible
 overhead involved in performing a bind."

Surely this is the exact scenario for which we are having this
discussion; a client using the directory to authenticate someone's
password to grant them access to another service.

>> * Clear statement that clients MUST provide a request
>> control if they want
>> the password policy to apply normally
>
>Are you saying here that the password policy should not be in
>effect if the
>client does not provide a request control? Maybe I did get you wrong?
>

I think my words just came out a little wrong.
I'm just saying that if a client does support the password policy control=
,
then they MUST provide it. Otherwise the directory may make some incorrec=
t
assumptions about the client, which will lead to the password policy
not being enforced normally. Eg. Bind failing due to pwdReset, instead of
succeeding.

Andrew Sciberras.

>Ciao, Michael.
>


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Fri Nov 21 10:11:26 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16704
	for <ldapext-archive@lists.ietf.org>; Fri, 21 Nov 2003 10:11:26 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANCw3-0004cC-1d; Fri, 21 Nov 2003 10:11:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANCvX-0004bP-KT
	for ldapext@optimus.ietf.org; Fri, 21 Nov 2003 10:10:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16597
	for <ldapext@ietf.org>; Fri, 21 Nov 2003 10:10:17 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANCvV-0003S9-00
	for ldapext@ietf.org; Fri, 21 Nov 2003 10:10:29 -0500
Received: from e5.ny.us.ibm.com ([32.97.182.105])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANCvU-0003Ry-00
	for ldapext@ietf.org; Fri, 21 Nov 2003 10:10:28 -0500
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hALF9s9n545716
	for <ldapext@ietf.org>; Fri, 21 Nov 2003 10:09:54 -0500
Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hALF9qmd074762
	for <ldapext@ietf.org>; Fri, 21 Nov 2003 10:09:53 -0500
Subject: RE: [ldapext] draft-behera-ldap-password-policy - bind behaviour when pwd
 must be changed
To: ldapext@ietf.org
X-Mailer: Lotus Notes Release 5.0.12   February 13, 2003
Message-ID: <OF8F391806.8D88BA20-ON86256DE5.0053067D-86256DE5.00534D51@us.ibm.com>
From: John McMeeking <jmcmeek@us.ibm.com>
Date: Fri, 21 Nov 2003 09:09:52 -0600
X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.5|September 18, 2003) at
 11/21/2003 09:09:53 AM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>





Andrew Sciberras wrote:

> I really believe that the compare should fail as well.
> The description for the 'Compare Operation':
> "The compare operation MAY be used to compare a password. This might
>  be performed when a client wishes to verify that user's supplied
>  password is correct. An example of this is an LDAP HTTP
>  authentication redirector. It may be desirable to use this rather
>  than performing a bind operation in order to reduce possible
>  overhead involved in performing a bind."
>
> Surely this is the exact scenario for which we are having this
> discussion; a client using the directory to authenticate someone's
> password to grant them access to another service.

I agree.  I forgot about compare in my discussions.


John  McMeeking


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Fri Nov 21 14:28:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27808
	for <ldapext-archive@lists.ietf.org>; Fri, 21 Nov 2003 14:28:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANGwj-0006XQ-IB; Fri, 21 Nov 2003 14:28:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANGwU-0006X9-Et
	for ldapext@optimus.ietf.org; Fri, 21 Nov 2003 14:27:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27777
	for <ldapext@ietf.org>; Fri, 21 Nov 2003 14:27:32 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANGwR-0007P5-00
	for ldapext@ietf.org; Fri, 21 Nov 2003 14:27:43 -0500
Received: from krl9-d9bb4cd5.pool.mediaways.net ([217.187.76.213] helo=nb2.stroeder.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANGwR-0007OY-00
	for ldapext@ietf.org; Fri, 21 Nov 2003 14:27:43 -0500
Received: from localhost (localhost [127.0.0.1])
	by nb2.stroeder.com (Postfix) with ESMTP
	id 73E429B799; Fri, 21 Nov 2003 20:27:06 +0100 (CET)
Received: from stroeder.com (localhost [127.0.0.1])
	by nb2.stroeder.com (Postfix) with ESMTP
	id 687879B747; Fri, 21 Nov 2003 20:27:05 +0100 (CET)
Message-ID: <3FBE6709.1030707@stroeder.com>
Date: Fri, 21 Nov 2003 20:27:05 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: andrews@adacel.com.au
Cc: "Ldapext (E-mail)" <ldapext@ietf.org>
Subject: Re: [ldapext] draft-behera-ldap-password-policy - bind behaviour
 when pwd must be changed
References: <005601c3afb7$a9e048b0$a618200a@mtwav.adacel.com.au>
In-Reply-To: <005601c3afb7$a9e048b0$a618200a@mtwav.adacel.com.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: by AMaViS 0.3.12pre8
Content-Transfer-Encoding: quoted-printable
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Andrew Sciberras wrote:
>>Michael Str=F6der wrote:
>>
>>BindRequest should fail. That's it.
>=20
> I really believe that the compare should fail as well.

Yes! Simply forgot that. Thanks for the reminder.

> I'm just saying that if a client does support the password policy contr=
ol,
> then they MUST provide it. Otherwise the directory may make some incorr=
ect
> assumptions about the client, which will lead to the password policy
> not being enforced normally. Eg. Bind failing due to pwdReset, instead =
of
> succeeding.

IMO "SHOULD provide it" and a short note will be sufficient here to make =

implementors aware of the issues.

If a LDAP client, which in principle supports password policy control, wa=
nts=20
to behave really dumb for some good reason it should be allowed to do so =

even if it does not look reasonable to us now. It then simply behaves lik=
e=20
any other dumb LDAP client out there.

Ciao, Michael.


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Sun Nov 23 18:39:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04569
	for <ldapext-archive@lists.ietf.org>; Sun, 23 Nov 2003 18:39:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AO3oj-0008Gh-AZ; Sun, 23 Nov 2003 18:39:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AO3o6-0008DW-FL
	for ldapext@optimus.ietf.org; Sun, 23 Nov 2003 18:38:22 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04548
	for <ldapext@ietf.org>; Sun, 23 Nov 2003 18:38:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AO3o3-0001Bi-00
	for ldapext@ietf.org; Sun, 23 Nov 2003 18:38:19 -0500
Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AO3ny-0001Ba-00
	for ldapext@ietf.org; Sun, 23 Nov 2003 18:38:14 -0500
Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16)
	id <B0001ab8b3>; Mon, 24 Nov 2003 10:30:07 +1100
Received: (qmail 20048 invoked from network); 23 Nov 2003 23:37:42 -0000
Received: from unknown (HELO shylock) (10.32.24.166)
  by nexus.adacel.com with SMTP; 23 Nov 2003 23:37:42 -0000
Reply-To: <andrews@adacel.com.au>
From: "Andrew Sciberras" <andrews@adacel.com.au>
To: "=?iso-8859-1?Q?'Michael_Str=F6der'?=" <michael@stroeder.com>
Cc: "Ldapext \(E-mail\)" <ldapext@ietf.org>
Subject: RE: [ldapext] draft-behera-ldap-password-policy - bind behaviour when pwd must be changed
Date: Mon, 24 Nov 2003 10:37:41 +1100
Message-ID: <001b01c3b21a$ca21c350$a618200a@mtwav.adacel.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3FBE6709.1030707@stroeder.com>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA04549
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable


Michael Str=F6der wrote:
>
>IMO "SHOULD provide it" and a short note will be sufficient
>here to make
>implementors aware of the issues.
>
>If a LDAP client, which in principle supports password policy
>control, wants
>to behave really dumb for some good reason it should be
>allowed to do so
>even if it does not look reasonable to us now. It then simply
>behaves like
>any other dumb LDAP client out there.
>
>Ciao, Michael.
>

Agreed. That all sounds pretty cool to me.


Andrew Sciberras.


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


From ldapext-admin@ietf.org  Sat Nov 29 20:25:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04504
	for <ldapext-archive@lists.ietf.org>; Sat, 29 Nov 2003 20:25:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQGKc-0005rM-LM; Sat, 29 Nov 2003 20:25:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQGJo-0005ql-04
	for ldapext@optimus.ietf.org; Sat, 29 Nov 2003 20:24:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04497
	for <ldapext@ietf.org>; Sat, 29 Nov 2003 20:23:57 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQGJl-0005yZ-00
	for ldapext@ietf.org; Sat, 29 Nov 2003 20:24:09 -0500
Received: from server1.montana.boreham.org ([63.112.219.168] helo=toad.mtbrook.boreham.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQGJl-0005yG-00
	for ldapext@ietf.org; Sat, 29 Nov 2003 20:24:09 -0500
Received: from PARSITE (unknown [63.112.219.180])
	by toad.mtbrook.boreham.org (Postfix) with ESMTP id BE5673FBF
	for <ldapext@ietf.org>; Sat, 29 Nov 2003 17:23:42 -0800 (PST)
Message-ID: <021101c3b6e2$3fe56c10$b4db703f@mtbrook.boreham.org>
From: "David Boreham" <david_list@boreham.org>
To: "Ldapext (E-mail)" <ldapext@ietf.org>
References: <04bf01c3a19a$3dcff420$a618200a@mtwav.adacel.com.au> <3FB087E7.6010605@stroeder.com> <000d01c3a828$5ce9f2e0$bddb703f@mtbrook.boreham.org> <3FB098AD.5090008@stroeder.com>
Subject: Re: [ldapext] draft-ietf-boreham-numsubordinates-01.txt
Date: Sat, 29 Nov 2003 17:35:34 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 7bit
Sender: ldapext-admin@ietf.org
Errors-To: ldapext-admin@ietf.org
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>,
	<mailto:ldapext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


>Simply add a note under security considerations. One can easily configure 
>access control like to any other attribute.

Agreed. From memory there was an earlier draft of
the document which was written this way, I'm happy
to regress back to that :)



_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext