From ldapext-bounces@ietf.org Thu May 04 22:40:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbqEP-00085F-Pz; Thu, 04 May 2006 22:39:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbq96-0006Aa-Fh for ldapext@ietf.org; Thu, 04 May 2006 22:34:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbpgs-0001tG-Vz for ldapext@ietf.org; Thu, 04 May 2006 22:05:11 -0400 Received: from mail17.ca.com ([155.35.248.106]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FbpUi-0005f8-7R for ldapext@ietf.org; Thu, 04 May 2006 21:52:38 -0400 Received: from ausyms11.ca.com ([155.35.201.2]) by mail17.ca.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 11:52:33 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 May 2006 11:52:32 +1000 Message-ID: <52681ACFF63C114F8A3C3651FC9D301F26AED2@AUSYMS11.ca.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Grace logins and password policy Thread-Index: AcZv5pLp6gS5oIWUQCW9W5s+skR4CA== From: "Ramsay, Ron" To: X-OriginalArrivalTime: 05 May 2006 01:52:33.0328 (UTC) FILETIME=[936E5300:01C66FE6] X-Spam-Score: -1.1 (-) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [ldapext] Grace logins and password policy X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Hi LDAPexters, At the moment the Behera draft (draft-behera-ldap-password-policy-08.txt) states that, once a password has expired, it will need to be reset. This reqires administrator intervention. Some vendors, implementing their own password policy mechanisms, allow a user to login with an expired password, forcing them to change it before proceeding. I believe there is business case for either method of expired password handling and that the Behera draft should address these. More specifically: If a user's password has expired and the number of grace logins has been exceeded then, at the vendor's discretion (or by configuration), a server can respond to a BIND request with either: 1) Bind Refuse - setting the LDAP response control error passwordExpired, requiring the user's password to be reset (current case); or 2) Bind Confirm - setting the LDAP response control error changeAfterReset, requiring the user to change their password before allowing other operations. The second option would seem a lot more manageable with a large user base. What do you think? Ron _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri May 05 07:17:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbyJG-0001aA-UN; Fri, 05 May 2006 07:17:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbyJF-0001Yz-Ip for ldapext@ietf.org; Fri, 05 May 2006 07:17:21 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbyJF-000767-5i for ldapext@ietf.org; Fri, 05 May 2006 07:17:21 -0400 Received: from phys-gadget-1 ([129.156.85.171]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k45BH6IN029591 for ; Fri, 5 May 2006 05:17:20 -0600 (MDT) Received: from conversion-daemon.gadget-mail1.uk.sun.com by gadget-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IYS00K01HW3C8@gadget-mail1.uk.sun.com> (original mail from Ludovic.Poitou@Sun.COM) for ldapext@ietf.org; Fri, 05 May 2006 12:17:19 +0100 (BST) Received: from [129.157.211.6] (pelisse.France.Sun.COM [129.157.211.6]) by gadget-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IYS00D4CI0TM9@gadget-mail1.uk.sun.com>; Fri, 05 May 2006 12:17:19 +0100 (BST) Date: Fri, 05 May 2006 13:18:47 +0200 From: Ludovic Poitou Subject: Re: [ldapext] Grace logins and password policy In-reply-to: <52681ACFF63C114F8A3C3651FC9D301F26AED2@AUSYMS11.ca.com> To: "Ramsay, Ron" Message-id: <445B3497.1000501@sun.com> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) References: <52681ACFF63C114F8A3C3651FC9D301F26AED2@AUSYMS11.ca.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Ramsay, Ron wrote: > Hi LDAPexters, > > At the moment the Behera draft > (draft-behera-ldap-password-policy-08.txt) states that, once a password > has expired, it will need to be reset. This reqires administrator > intervention. Once the password has expired, it needs to be changed (or reset). This requires administrative rights, not necessarily an administrator intervention. > Some vendors, implementing their own password policy > mechanisms, allow a user to login with an expired password, forcing them > to change it before proceeding. > > I believe there is business case for either method of expired password > handling and that the Behera draft should address these. > > More specifically: > > If a user's password has expired and the number of grace logins has been > exceeded then, at the vendor's discretion (or by configuration), a > server can respond to a BIND request with either: > > 1) Bind Refuse - setting the LDAP response control error > passwordExpired, requiring the user's password to be reset (current > case); > > or > > 2) Bind Confirm - setting the LDAP response control error > changeAfterReset, requiring the user to change their password before > allowing other operations. > > The second option would seem a lot more manageable with a large user > base. > > What do you think? > I would consider that option 2 is actually defeating the password policy and the grace login mechanism. The main issue for letting user authenticate with an expired password but requiring the user to change their password before allowing other operations, is that often there are several applications using the directory server, some are only doing authentication and nothing more. These applications, ignoring the requirement to change the password, can continue to authenticate expired users forever. Users do not directly interact with the LDAP server, they are usually interact with applications that are using LDAP. There should be another application available to users to allow them to do a self reset of the password. This application should first verify the identity of the user by other means such as asking secret questions, and then proceed to the password change using an application specific identity which has the appropriate access rights. An alternate solution solely based on LDAP could be to allow the use of the Password Modify Extended Operation under SSL as an anonymous users, only if the old password is provided and matches the expired password. Regards, Ludovic. > Ron > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > -- Ludovic Poitou Sun Microsystems Inc. Software Architect Directory Server Group http://blogs.sun.com/Ludo/ Grenoble, France Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Sun May 07 22:27:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcvS6-0006sa-CV; Sun, 07 May 2006 22:26:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcvS5-0006m5-3v for ldapext@ietf.org; Sun, 07 May 2006 22:26:25 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcvS2-0002L7-Ri for ldapext@ietf.org; Sun, 07 May 2006 22:26:25 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k482QMJE017865 for ; Sun, 7 May 2006 22:26:22 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k482QLeG171262 for ; Sun, 7 May 2006 22:26:21 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k482QLSi019159 for ; Sun, 7 May 2006 22:26:21 -0400 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.229.77]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k482QLRs019154 for ; Sun, 7 May 2006 22:26:21 -0400 To: ldapext@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: John McMeeking Message-ID: Date: Sun, 7 May 2006 21:26:20 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 7.0.1|January 17, 2006) at 05/07/2006 09:26:21 PM, Serialize complete at 05/07/2006 09:26:21 PM X-Spam-Score: 1.8 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [ldapext] password policy response control question X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0349125052==" Errors-To: ldapext-bounces@ietf.org --===============0349125052== Content-Type: text/html; charset="US-ASCII"
What response should the server send if there are no password policy warnings or errors to report?

I've heard several answers proposed on my team, along with arguments for and against:

1.  Do not send a password policy response control.
2.  Send a response control with no value.
3.  Send a response control where the value consists of an empty sequence.

The draft says that responses are sent "when appropriate", and there is a general rule that protocols shouldn't be unnecessarily "chatty".  Not sending a response fits both those criteria, but some have argued that not sending this control should be interpreted as meaning the server does not support the control (perhaps the control is not supported with a particular naming context) .  Control values are optional for LDAP controls in general.  The draft doesn't say the response MUST be sent with a control value; neither does it state any condition under which the server would send a response control without a warning or error.

The converse of the question might be:  What should a client expect as normal responses?


John  McMeeking
 --===============0349125052== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0349125052==-- From ldapext-bounces@ietf.org Sun May 07 22:48:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcvnR-0004wQ-In; Sun, 07 May 2006 22:48:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcvnQ-0004wI-Dw for ldapext@ietf.org; Sun, 07 May 2006 22:48:28 -0400 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcvnO-0003Cg-3D for ldapext@ietf.org; Sun, 07 May 2006 22:48:28 -0400 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id k482mJSt008385; Sun, 7 May 2006 21:48:20 -0500 Message-ID: <445EB178.9070507@highlandsun.com> Date: Sun, 07 May 2006 19:48:24 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060427 SeaMonkey/1.5a MIME-Version: 1.0 To: John McMeeking Subject: Re: [ldapext] password policy response control question References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org John McMeeking wrote: > > What response should the server send if there are no password policy > warnings or errors to report? > > I've heard several answers proposed on my team, along with arguments for > and against: > > 1. Do not send a password policy response control. > 2. Send a response control with no value. > 3. Send a response control where the value consists of an empty sequence. The OpenLDAP implementation does (3). If I were writing a client, I'm not sure I'd care. For an unsupported control, you would get a specific error already. So, absent that error, I would assume all's well. > The draft says that responses are sent "when appropriate", and there is > a general rule that protocols shouldn't be unnecessarily "chatty". Not > sending a response fits both those criteria, but some have argued that > not sending this control should be interpreted as meaning the server > does not support the control (perhaps the control is not supported with > a particular naming context) . Control values are optional for LDAP > controls in general. The draft doesn't say the response MUST be sent > with a control value; neither does it state any condition under which > the server would send a response control without a warning or error. > > The converse of the question might be: What should a client expect as > normal responses? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Sun May 07 22:54:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcvsU-00087v-I6; Sun, 07 May 2006 22:53:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcvsT-00087l-Az for ldapext@ietf.org; Sun, 07 May 2006 22:53:41 -0400 Received: from mail17.ca.com ([155.35.248.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcvsQ-0003Ml-HT for ldapext@ietf.org; Sun, 07 May 2006 22:53:41 -0400 Received: from ausyms11.ca.com ([155.35.201.2]) by mail17.ca.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 12:53:28 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ldapext] password policy response control question Date: Mon, 8 May 2006 12:53:26 +1000 Message-ID: <52681ACFF63C114F8A3C3651FC9D301F26B08C@AUSYMS11.ca.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ldapext] password policy response control question Thread-Index: AcZyRyQ2EwAG4JQiTpKOon1QJOFIyQAAlDAw From: "Ramsay, Ron" To: "John McMeeking" , X-OriginalArrivalTime: 08 May 2006 02:53:28.0292 (UTC) FILETIME=[9532D240:01C6724A] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0086029184==" Errors-To: ldapext-bounces@ietf.org This is a multi-part message in MIME format. --===============0086029184== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6724A.9518B5D5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6724A.9518B5D5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, =20 The question of whether to send a response ("when appropriate") has come up before and has not been resolved. I'd like to put a stake in the ground and say that a response should always be sent if the control is understood (that is, if the server supports the control). =20 Further, I'd like to suggest that, in the case where there is no data to be sent, the value be absent. =20 Ron ________________________________ From: John McMeeking [mailto:jmcmeek@us.ibm.com]=20 Sent: Monday, 8 May 2006 12:26 PM To: ldapext@ietf.org Subject: [ldapext] password policy response control question What response should the server send if there are no password policy warnings or errors to report?=20 I've heard several answers proposed on my team, along with arguments for and against:=20 1. Do not send a password policy response control.=20 2. Send a response control with no value.=20 3. Send a response control where the value consists of an empty sequence.=20 The draft says that responses are sent "when appropriate", and there is a general rule that protocols shouldn't be unnecessarily "chatty". Not sending a response fits both those criteria, but some have argued that not sending this control should be interpreted as meaning the server does not support the control (perhaps the control is not supported with a particular naming context) . Control values are optional for LDAP controls in general. The draft doesn't say the response MUST be sent with a control value; neither does it state any condition under which the server would send a response control without a warning or error.=20 The converse of the question might be: What should a client expect as normal responses?=20 John McMeeking ------_=_NextPart_001_01C6724A.9518B5D5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi John,
 
The question of whether to send a response = ("when=20 appropriate") has come up before and has not been resolved. I'd like to = put a=20 stake in the ground and say that a response should always be sent if the = control=20 is understood (that is, if the server supports the = control).
 
Further, I'd like to suggest that, in the case=20 where there is no data to be sent, the value be=20 absent.
 
Ron

From: John McMeeking = [mailto:jmcmeek@us.ibm.com]=20
Sent: Monday, 8 May 2006 12:26 PM
To:=20 ldapext@ietf.org
Subject: [ldapext] password policy response = control=20 question


What response should the = server send=20 if there are no password policy warnings or errors to report?=20

I've heard several answers = proposed on my=20 team, along with arguments for and against:

1.  Do not send a password policy response control. =
2.  Send a response control with no = value.=20
3.  Send a response = control where=20 the value consists of an empty sequence.

The draft says that responses are sent "when appropriate", and = there is a=20 general rule that protocols shouldn't be unnecessarily "chatty". =  Not=20 sending a response fits both those criteria, but some have argued that = not=20 sending this control should be interpreted as meaning the server does = not=20 support the control (perhaps the control is not supported with a = particular=20 naming context) .  Control values are optional for LDAP controls in = general.  The draft doesn't say the response MUST be sent with a = control=20 value; neither does it state any condition under which the server would = send a=20 response control without a warning or error.

The converse of the question might be: =  What should=20 a client expect as normal responses?


John  McMeeking
 ------_=_NextPart_001_01C6724A.9518B5D5-- --===============0086029184== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0086029184==-- From ldapext-bounces@ietf.org Mon May 08 04:20:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd0xe-0004wF-BA; Mon, 08 May 2006 04:19:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd0xd-0004wA-J3 for ldapext@ietf.org; Mon, 08 May 2006 04:19:21 -0400 Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd0xc-0006QI-5a for ldapext@ietf.org; Mon, 08 May 2006 04:19:21 -0400 Received: from ns1.sys-net.it (localhost [127.0.0.1]) by mail.sys-net.it (8.13.5.20060308/8.13.3) with ESMTP id k488H1eV008582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 May 2006 10:17:01 +0200 Received: (from apache@localhost) by ns1.sys-net.it (8.13.5.20060308/8.12.5/Submit) id k488H0Js008572; Mon, 8 May 2006 10:17:00 +0200 Received: from 131.175.154.56 (SquirrelMail authenticated user ando); by webmail.sys-net.it with HTTP; Mon, 8 May 2006 10:17:00 +0200 (CEST) Message-ID: <33821.131.175.154.56.1147076220.squirrel@131.175.154.56> In-Reply-To: <52681ACFF63C114F8A3C3651FC9D301F26B08C@AUSYMS11.ca.com> References: <52681ACFF63C114F8A3C3651FC9D301F26B08C@AUSYMS11.ca.com> Date: Mon, 8 May 2006 10:17:00 +0200 (CEST) Subject: RE: [ldapext] password policy response control question From: "Pierangelo Masarati" To: "Ramsay, Ron" User-Agent: SquirrelMail/1.4.3a-1 X-Mailer: SquirrelMail/1.4.3a-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-2.0.2 (mail.sys-net.it [127.0.0.1]); Mon, 08 May 2006 10:17:01 +0200 (CEST) X-Spam-Status: No, score=-4.4 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on www.sys-net.it X-SysNet-MailScanner-Information: postmaster@sys-net.it X-SysNet-MailScanner: X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: John McMeeking , ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ando@sys-net.it List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org > Hi John, > > The question of whether to send a response ("when appropriate") has come > up before and has not been resolved. I'd like to put a stake in the > ground and say that a response should always be sent if the control is > understood (that is, if the server supports the control). Ron, the fact that the control is understood is guaranteed by the fact that the DSA didn't reject the request with unavailableCriticalExtension; it would be acceptable for the control response to be absent if not needed. This is true, of course for critical controls. I'd favor this case. > Further, I'd like to suggest that, in the case where there is no data to > be sent, the value be absent. this should be the behavior when the control is not critical. p. Ing. Pierangelo Masarati Responsabile Open Solution OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon May 08 04:29:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd177-00042O-DS; Mon, 08 May 2006 04:29:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd175-00042J-MD for ldapext@ietf.org; Mon, 08 May 2006 04:29:08 -0400 Received: from mail17.ca.com ([155.35.248.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd173-0006nG-49 for ldapext@ietf.org; Mon, 08 May 2006 04:29:07 -0400 Received: from ausyms11.ca.com ([155.35.201.2]) by mail17.ca.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 18:29:03 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] Grace logins and password policy Date: Mon, 8 May 2006 18:29:01 +1000 Message-ID: <52681ACFF63C114F8A3C3651FC9D301F26B172@AUSYMS11.ca.com> In-Reply-To: <445B3497.1000501@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ldapext] Grace logins and password policy Thread-Index: AcZwNaNTvcCeYCzEQaarhb7bDpbZegCQtrGA From: "Ramsay, Ron" To: "Ludovic Poitou" X-OriginalArrivalTime: 08 May 2006 08:29:03.0311 (UTC) FILETIME=[769AE5F0:01C67279] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Thanks for your reply, Ludovic. I have some more comments. I'm happy that it is possible to set up self service systems (with administrative privileges) to handle resetting passwords after grace logins have been exceeded. I agree that option 2 defeats the purpose of a grace login mechanism. I'm not sure that applications implementing the password policy control can authenticate and nothing more. If a password is reset then it would never need changing as 'changeAfterReset' would be ignored. The main point I was making is that some vendors, implementing their own password policy mechanisms, allow a login with an expired password, forcing a change before proceeding. But you are correct in that these environments don't support grace logins. Applications built using the Netscape (expired) control & Microsoft domain logins are examples. Perhaps, in the absence of 'pwdGraceLoginLimit' (or if it has a value of zero), the directory could respond exactly as it does for a reset password? That is, could we make grace logins optional? Ron -----Original Message----- From: Ludovic Poitou [mailto:Ludovic.Poitou@Sun.COM]=20 Sent: Friday, 5 May 2006 9:19 PM To: Ramsay, Ron Cc: ldapext@ietf.org Subject: Re: [ldapext] Grace logins and password policy Ramsay, Ron wrote: > Hi LDAPexters, > > At the moment the Behera draft > (draft-behera-ldap-password-policy-08.txt) states that, once a=20 > password has expired, it will need to be reset. This reqires=20 > administrator intervention. Once the password has expired, it needs to be changed (or reset). This requires administrative rights, not necessarily an administrator intervention. > Some vendors, implementing their own password policy mechanisms,=20 > allow a user to login with an expired password, forcing them to change > it before proceeding. > =20 > I believe there is business case for either method of expired password > handling and that the Behera draft should address these. > > More specifically: > > If a user's password has expired and the number of grace logins has=20 > been exceeded then, at the vendor's discretion (or by configuration),=20 > a server can respond to a BIND request with either: > > 1) Bind Refuse - setting the LDAP response control error=20 > passwordExpired, requiring the user's password to be reset (current=20 > case); > > or > > 2) Bind Confirm - setting the LDAP response control error=20 > changeAfterReset, requiring the user to change their password before=20 > allowing other operations. > > The second option would seem a lot more manageable with a large user=20 > base. > > What do you think? > =20 I would consider that option 2 is actually defeating the password policy and the grace login mechanism. The main issue for letting user authenticate with an expired password but requiring the user to change their password before allowing other operations, is that often there are several applications using the directory server, some are only doing authentication and nothing more.=20 These applications, ignoring the requirement to change the password, can continue to authenticate expired users forever. Users do not directly interact with the LDAP server, they are usually interact with applications that are using LDAP. There should be another application available to users to allow them to do a self reset of the password. This application should first verify the identity of the user by other means such as asking secret questions, and then proceed to the password change using an application specific identity which has the appropriate access rights. An alternate solution solely based on LDAP could be to allow the use of the Password Modify Extended Operation under SSL as an anonymous users, only if the old password is provided and matches the expired password. Regards, Ludovic. > Ron > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > =20 --=20 Ludovic Poitou Sun Microsystems Inc. Software Architect Directory Server Group http://blogs.sun.com/Ludo/ Grenoble, France Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon May 08 04:43:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd1Km-0007J0-Ja; Mon, 08 May 2006 04:43:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd1Kk-0007Iv-SI for ldapext@ietf.org; Mon, 08 May 2006 04:43:14 -0400 Received: from mail17.ca.com ([155.35.248.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd1Ki-0007QP-Dm for ldapext@ietf.org; Mon, 08 May 2006 04:43:14 -0400 Received: from ausyms11.ca.com ([155.35.201.2]) by mail17.ca.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 18:43:11 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] password policy response control question Date: Mon, 8 May 2006 18:43:11 +1000 Message-ID: <52681ACFF63C114F8A3C3651FC9D301F26B175@AUSYMS11.ca.com> In-Reply-To: <33821.131.175.154.56.1147076220.squirrel@131.175.154.56> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ldapext] password policy response control question Thread-Index: AcZyeCGUud18oeLuSySHwF3jYdkuagAAZSaQ From: "Ramsay, Ron" To: X-OriginalArrivalTime: 08 May 2006 08:43:11.0009 (UTC) FILETIME=[6FDF5910:01C6727B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: John McMeeking , ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Hmmm. I didn't think the control was required to be marked 'critical' but, if it is, then you are correct that the control will have been recognised if the request was performed. (Your remark "when the control is not critical" makes me believe that you don't understand the use of the criticality flag. For example, you cannot respond with "unavailableCriticalExtension" if the control is not marked critical.) I don't see how whether a response control is sent is related to whether the control is critical. Originally, the idea was that whether the control was marked critical or not, processing should be the same. This may have changed recently with Kurt's remarks on the behaviour of modules in OpenLDAP and also with reference to distributed operations. Therefore, it is simply a preference whether a control on the request is matched with one on the response. I am in favour of this always being the case. Two of the most troublesome operations in LDAP are Abandon and Unbind, simply because they are not confirmed operations. Please let's have this control 'confirmed'. Also, I don't believe it is required to be marked 'critical', so a response control will set the client at ease. Ron -----Original Message----- From: Pierangelo Masarati [mailto:ando@sys-net.it]=20 Sent: Monday, 8 May 2006 6:17 PM To: Ramsay, Ron Cc: John McMeeking; ldapext@ietf.org Subject: RE: [ldapext] password policy response control question > Hi John, > > The question of whether to send a response ("when appropriate") has=20 > come up before and has not been resolved. I'd like to put a stake in=20 > the ground and say that a response should always be sent if the=20 > control is understood (that is, if the server supports the control). Ron, the fact that the control is understood is guaranteed by the fact that the DSA didn't reject the request with unavailableCriticalExtension; it would be acceptable for the control response to be absent if not needed. This is true, of course for critical controls. I'd favor this case. > Further, I'd like to suggest that, in the case where there is no data=20 > to be sent, the value be absent. this should be the behavior when the control is not critical. p. Ing. Pierangelo Masarati Responsabile Open Solution OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 =20 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon May 08 05:46:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd2JG-0004Zf-Cv; Mon, 08 May 2006 05:45:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd2JF-0004Za-7v for ldapext@ietf.org; Mon, 08 May 2006 05:45:45 -0400 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd2JC-0001tr-Rr for ldapext@ietf.org; Mon, 08 May 2006 05:45:45 -0400 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id k489hSp3017579; Mon, 8 May 2006 04:43:34 -0500 Message-ID: <445F12C6.5080600@highlandsun.com> Date: Mon, 08 May 2006 02:43:34 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060427 SeaMonkey/1.5a MIME-Version: 1.0 To: "Ramsay, Ron" Subject: Re: [ldapext] password policy response control question References: <52681ACFF63C114F8A3C3651FC9D301F26B175@AUSYMS11.ca.com> In-Reply-To: <52681ACFF63C114F8A3C3651FC9D301F26B175@AUSYMS11.ca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org I agree with most of the points here, and it aligns with our rationale in writing the OpenLDAP implementation. Also my reading of section 6.2 of the draft: 6.2 Response Control If the client has sent a passwordPolicyRequest control, the server (when solicited by the inclusion of the request control) sends this control with the following operation responses: bindResponse, modifyResponse, addResponse, compareResponse and possibly extendedResponse, to inform of various conditions, and MAY be sent with other operations (in the case of the changeAfterReset error). I interpret "the server ... sends this control" as "the server SHALL send this control..." But that's a separate question (whether the response control is sent at all) from the original query (whether the control value should be present in the response control). Still, the use of the control by the client is purely for informative purposes; the policies will take effect on the server regardless. As such, if the client really really wants to know that an operation succeeded in full conformance with the policy, then the client should set criticality TRUE in the request. Ramsay, Ron wrote: > Hmmm. I didn't think the control was required to be marked 'critical' > but, if it is, then you are correct that the control will have been > recognised if the request was performed. (Your remark "when the control > is not critical" makes me believe that you don't understand the use of > the criticality flag. For example, you cannot respond with > "unavailableCriticalExtension" if the control is not marked critical.) > > I don't see how whether a response control is sent is related to whether > the control is critical. Originally, the idea was that whether the > control was marked critical or not, processing should be the same. This > may have changed recently with Kurt's remarks on the behaviour of > modules in OpenLDAP and also with reference to distributed operations. > > Therefore, it is simply a preference whether a control on the request is > matched with one on the response. I am in favour of this always being > the case. Two of the most troublesome operations in LDAP are Abandon and > Unbind, simply because they are not confirmed operations. Please let's > have this control 'confirmed'. > > Also, I don't believe it is required to be marked 'critical', so a > response control will set the client at ease. > > Ron > > > -----Original Message----- > From: Pierangelo Masarati [mailto:ando@sys-net.it] > Sent: Monday, 8 May 2006 6:17 PM > To: Ramsay, Ron > Cc: John McMeeking; ldapext@ietf.org > Subject: RE: [ldapext] password policy response control question > >> Hi John, >> >> The question of whether to send a response ("when appropriate") has >> come up before and has not been resolved. I'd like to put a stake in >> the ground and say that a response should always be sent if the >> control is understood (that is, if the server supports the control). > > Ron, > > the fact that the control is understood is guaranteed by the fact that > the DSA didn't reject the request with unavailableCriticalExtension; it > would be acceptable for the control response to be absent if not needed. > This is true, of course for critical controls. I'd favor this case. > >> Further, I'd like to suggest that, in the case where there is no data >> to be sent, the value be absent. > > this should be the behavior when the control is not critical. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon May 08 06:03:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd2aP-0001hK-Iz; Mon, 08 May 2006 06:03:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd2aO-0001hF-Lr for ldapext@ietf.org; Mon, 08 May 2006 06:03:28 -0400 Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd2aM-00032X-7Z for ldapext@ietf.org; Mon, 08 May 2006 06:03:28 -0400 Received: from ns1.sys-net.it (localhost [127.0.0.1]) by mail.sys-net.it (8.13.5.20060308/8.13.3) with ESMTP id k48A37tx020397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 May 2006 12:03:07 +0200 Received: (from apache@localhost) by ns1.sys-net.it (8.13.5.20060308/8.12.5/Submit) id k48A35YL020394; Mon, 8 May 2006 12:03:05 +0200 Received: from 131.175.154.56 (SquirrelMail authenticated user ando); by webmail.sys-net.it with HTTP; Mon, 8 May 2006 12:03:04 +0200 (CEST) Message-ID: <34131.131.175.154.56.1147082584.squirrel@131.175.154.56> In-Reply-To: <52681ACFF63C114F8A3C3651FC9D301F26B175@AUSYMS11.ca.com> References: <33821.131.175.154.56.1147076220.squirrel@131.175.154.56> <52681ACFF63C114F8A3C3651FC9D301F26B175@AUSYMS11.ca.com> Date: Mon, 8 May 2006 12:03:04 +0200 (CEST) Subject: RE: [ldapext] password policy response control question From: "Pierangelo Masarati" To: "Ramsay, Ron" User-Agent: SquirrelMail/1.4.3a-1 X-Mailer: SquirrelMail/1.4.3a-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-2.0.2 (mail.sys-net.it [127.0.0.1]); Mon, 08 May 2006 12:03:07 +0200 (CEST) X-Spam-Status: No, score=-4.4 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on www.sys-net.it X-SysNet-MailScanner-Information: postmaster@sys-net.it X-SysNet-MailScanner: X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: John McMeeking , ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ando@sys-net.it List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org > Hmmm. I didn't think the control was required to be marked 'critical' from The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality may be TRUE or FALSE. There is no controlValue. > but, if it is, then you are correct that the control will have been > recognised if the request was performed. (Your remark "when the control > is not critical" makes me believe that you don't understand the use of > the criticality flag. For example, you cannot respond with > "unavailableCriticalExtension" if the control is not marked critical.) I believe I understand it. That's why I agree that if no criticality was set in the request, a control response with no value should be sent to clarify that the DSA understood the control. > I don't see how whether a response control is sent is related to whether > the control is critical. If the control response does not add to the knowledge of the client, it's a waste of resources. I believe this is the case if the control criticality is set but the control response would be empty. The draft correctly does not require an empty control response to be returned. > Originally, the idea was that whether the > control was marked critical or not, processing should be the same. If the control is recognized, yes. If it's not, processing changes quite a bit. > This > may have changed recently with Kurt's remarks on the behaviour of > modules in OpenLDAP and also with reference to distributed operations. > > Therefore, it is simply a preference whether a control on the request is > matched with one on the response. I am in favour of this always being > the case. Two of the most troublesome operations in LDAP are Abandon and > Unbind, simply because they are not confirmed operations. Please let's > have this control 'confirmed'. > > Also, I don't believe it is required to be marked 'critical', so a > response control will set the client at ease. No, it's not. My suggestion is about not wasting resources. I don't mind too much about badly written clients (things like: since I sent the control request, there must be a control response, so I don't even check it's there are nonsense). In "modern" LDAP client writing, developers should never assume anything but correctness and, when possible, efficiency. I think a response that doesn't add to what the client already knows is inefficient. Another point is: this control is about security; I don't like risking that a security related control is ignored just because I'm too lazy to mark the request as critical. If I send the request I'd first make sure the server supports it, and then requite it to process my request accordingly. p. Ing. Pierangelo Masarati Responsabile Open Solution OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon May 08 08:40:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd51m-0003jn-0a; Mon, 08 May 2006 08:39:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd51l-0003ji-44 for ldapext@ietf.org; Mon, 08 May 2006 08:39:53 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd51k-0006AY-Jl for ldapext@ietf.org; Mon, 08 May 2006 08:39:53 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k48CdqIm014413 for ; Mon, 8 May 2006 08:39:52 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k48Cdqih239680 for ; Mon, 8 May 2006 08:39:52 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k48CdqMv021038 for ; Mon, 8 May 2006 08:39:52 -0400 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.229.77]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k48CdpdH021027 for ; Mon, 8 May 2006 08:39:51 -0400 In-Reply-To: <52681ACFF63C114F8A3C3651FC9D301F26B172@AUSYMS11.ca.com> To: ldapext@ietf.org Subject: RE: [ldapext] Grace logins and password policy MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: John McMeeking Message-ID: Date: Mon, 8 May 2006 07:39:50 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 7.0.1|January 17, 2006) at 05/08/2006 07:39:51 AM, Serialize complete at 05/08/2006 07:39:51 AM X-Spam-Score: 1.6 (+) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1206044702==" Errors-To: ldapext-bounces@ietf.org --===============1206044702== Content-Type: text/html; charset="US-ASCII"
I fear I'm rehashing old arguments, but...

"Ramsay, Ron" <Ron.Ramsay@ca.com> wrote on 05/08/2006 03:29:01 AM:

> Thanks for your reply, Ludovic. I have some more comments.
>
> I'm happy that it is possible to set up self service systems (with
> administrative privileges) to handle resetting passwords after grace
> logins have been exceeded.
>
> I agree that option 2 defeats the purpose of a grace login mechanism.
>
> I'm not sure that applications implementing the password policy control
> can authenticate and nothing more. If a password is reset then it would
> never need changing as 'changeAfterReset' would be ignored.

Consider use of LDAP authentication to access a web site.  For the web servers I am familiar with, a logon request results in something like the following:

- server, under its own identity, searches for user "john", gets search entry uid=john,cn=users,...
- server, under a separate connection, binds as uid=john,cn=users,...  The bind request may contain a password policy response (or the web server may not know about password policy at all)
- if the bind request is successful, the server, under its original connection, retrieves group or or other information about uid=john,cn=users,... for authorization, personalization, or other purposes.

With this usage, the only operation performed under the user's identity is the initial bind request.  At least with respect to operations performed under the user's identity, I think this would meet the criteria of an application that might use password policy to authenticate and nothing more.  Password changes might be done under another identity.  I commonly see deployments where users do not change their passwords directly through LDAP, but through some application that runs under its own identity.

As Ludovic pointed out, any application which does not use password policy - and for some directory deployments, the existance of such applications may be a long-term condition - a bind request that would have resulted in a password policy warning is only seen as a successful bind.

> The main point I was making is that some vendors, implementing their own
> password policy mechanisms, allow a login with an expired password,
> forcing a change before proceeding. But you are correct in that these
> environments don't support grace logins. Applications built using the
> Netscape (expired) control & Microsoft domain logins are examples.
>
> Perhaps, in the absence of 'pwdGraceLoginLimit' (or if it has a value of
> zero), the directory could respond exactly as it does for a reset
> password? That is, could we make grace logins optional?
In the case of "change after reset" error (or expiration warning, or...), a password-policy aware web server - or other application - might examine the bind response controls and redirect the user to a password change form.

In the case of an application that can perform password changes under an administrative identity, it should suffice for an expired password to fail with a "password expired" error.  The application should be able to examine the bind response control and redirect the user to a password change application.  An application that does not use password policy, I think, must see a bind failure for expired or reset passwords.

I have heard arguments for a case where an application that does not use password policy controls might check for expired or reset passwords by doing its own searches to retrieve password policy operational attributes.  In that case, the application needs to be able to determine that the provided password was correct, which suggests a successful bind result.  The example given was that of a user developed web application, where the web server might use LDAP authentication and be password policy ignorant, and the user application provided the password policy support.  The web server needs the successful bind for reset or expired passwords.  This isn't all that far fetched.  Web server support for password policy might not be available for some time, while user applications may be able to adopt password policy more quickly.

This is probably an argument for providing more options for server behavior than I would care to address in this draft.  It is also an argument for separating client observable bind/compare request responses behavior from policy administration.  I am not sure where I would put password change policy and its responses.  It has never been clear to me that there was much need for a standard password policy administration model unless you are interested in a multi-vendor distributed directory, and that begs for common access control, replication, and other support.  Certainly there is need for a common client model.
>
> Ron
>
> -----Original Message-----
> From: Ludovic Poitou [mailto:Ludovic.Poitou@Sun.COM]
> Sent: Friday, 5 May 2006 9:19 PM
> To: Ramsay, Ron
> Cc: ldapext@ietf.org
> Subject: Re: [ldapext] Grace logins and password policy
>
>
>
> Ramsay, Ron wrote:
> > Hi LDAPexters,
> >
> > At the moment the Behera draft
> > (draft-behera-ldap-password-policy-08.txt) states that, once a
> > password has expired, it will need to be reset. This reqires
> > administrator intervention.
> Once the password has expired, it needs to be changed (or reset). This
> requires administrative rights, not necessarily an administrator
> intervention.
>
> >  Some vendors, implementing their own password policy mechanisms,
> > allow a user to login with an expired password, forcing them to change
>
> > it before proceeding.
> >  
> > I believe there is business case for either method of expired password
>
> > handling and that the Behera draft should address these.
> >
> > More specifically:
> >
> > If a user's password has expired and the number of grace logins has
> > been exceeded then, at the vendor's discretion (or by configuration),
> > a server can respond to a BIND request with either:
> >
> > 1) Bind Refuse - setting the LDAP response control error
> > passwordExpired, requiring the user's password to be reset (current
> > case);
> >
> > or
> >
> > 2) Bind Confirm - setting the LDAP response control error
> > changeAfterReset, requiring the user to change their password before
> > allowing other operations.
> >
> > The second option would seem a lot more manageable with a large user
> > base.
> >
> > What do you think?
> >  
> I would consider that option 2 is actually defeating the password policy
> and the grace login mechanism.
> The main issue for letting user authenticate with an expired password
> but requiring the user to change their password before allowing other
> operations, is that often there are several applications using the
> directory server, some are only doing authentication and nothing more.
> These applications, ignoring the requirement to change the password, can
> continue to authenticate expired users forever.
> Users do not directly interact with the LDAP server, they are usually
> interact with applications that are using LDAP. There should be another
> application available to users to allow them to do a self reset of the
> password. This application should first verify the identity of the user
> by other means such as asking secret questions, and then proceed to the
> password change using an application specific identity which has the
> appropriate access rights.
>
> An alternate solution solely based on LDAP could be to allow the use of
> the Password Modify Extended Operation under SSL as an anonymous users,
> only if the old password is provided and matches the expired password.
>
> Regards,
>
> Ludovic.
>
>
>
>
> > Ron
> >
> > _______________________________________________
> > Ldapext mailing list
> > Ldapext@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ldapext
> >  
>
> --
> Ludovic Poitou                                    Sun Microsystems Inc.
> Software Architect                               Directory Server Group
> http://blogs.sun.com/Ludo/                             Grenoble, France
>
> 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
John  McMeeking
 --===============1206044702== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============1206044702==-- From ldapext-bounces@ietf.org Mon May 08 14:12:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdADD-00065g-3s; Mon, 08 May 2006 14:12:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdADB-00065b-H3 for ldapext@ietf.org; Mon, 08 May 2006 14:12:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdADB-0007q3-Et for ldapext@ietf.org; Mon, 08 May 2006 14:12:01 -0400 Received: from boole.openldap.org ([204.152.186.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FdAD9-0001Nq-Ee for ldapext@ietf.org; Mon, 08 May 2006 14:12:01 -0400 Received: from gypsy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k48IBvES028180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 May 2006 18:11:57 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.1.0.0.20060507224346.036464e0@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 08 May 2006 11:11:34 -0700 To: John McMeeking From: "Kurt D. Zeilenga" Subject: Re: [ldapext] password policy response control question In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -2.6 (--) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org At 07:26 PM 5/7/2006, John McMeeking wrote: >What response should the server send if there are no password policy warnings or errors to report? > >I've heard several answers proposed on my team, along with arguments for and against: > >1. Do not send a password policy response control. >2. Send a response control with no value. >3. Send a response control where the value consists of an empty sequence. IIRC, 2) would violate the control specification. The control value is a BER-encoded instance of a SEQUENCE with some optional fields. One could change the specification to state that, in lieu of sending an empty sequence, no control value MUST/SHOULD/MAY be provided. However, doing so 1) can complicate implementations and 2) (in the SHOULD/MAY case) can lead to interoperability problems. >The draft says that responses are sent "when appropriate", and there is a general rule that protocols shouldn't be unnecessarily "chatty". The "chatty" rule is not applicable here. A protocol is not unnecessary chatty simply because the rules used to encode a value is not minimally compact. I note that there is value in the protocol being simple. Having multiple encoding rules for the same or different abstract values of the same type is unnecessarily complex. >Not sending a response fits both those criteria, but some have argued that not sending this control should be interpreted as meaning the server does not support the control (perhaps the control is not supported with a particular naming context) . Control values are optional for LDAP controls in general. The draft doesn't say the response MUST be sent with a control value; neither does it state any condition under which the server would send a response control without a warning or error. > >The converse of the question might be: What should a client expect as normal responses? > > >John McMeeking >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon May 08 19:06:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdEnO-0000Eb-4p; Mon, 08 May 2006 19:05:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdEnM-0000ER-P2 for ldapext@ietf.org; Mon, 08 May 2006 19:05:40 -0400 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdEnL-0007J2-H1 for ldapext@ietf.org; Mon, 08 May 2006 19:05:40 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k48N3YxZ002280; Mon, 8 May 2006 19:03:35 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k48N3YT2009998; Mon, 8 May 2006 19:03:34 -0400 Received: from [172.16.25.166] (dhcp-172-16-25-166.sfbay.redhat.com [172.16.25.166]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k48N3Vpl019717; Mon, 8 May 2006 19:03:32 -0400 Message-ID: <445FCE43.3070307@redhat.com> Date: Mon, 08 May 2006 16:03:31 -0700 From: Pete Rowley User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: ando@sys-net.it Subject: Re: [ldapext] password policy response control question References: <33821.131.175.154.56.1147076220.squirrel@131.175.154.56> <52681ACFF63C114F8A3C3651FC9D301F26B175@AUSYMS11.ca.com> <34131.131.175.154.56.1147082584.squirrel@131.175.154.56> In-Reply-To: <34131.131.175.154.56.1147082584.squirrel@131.175.154.56> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: ldapext@ietf.org, John McMeeking , "Ramsay, Ron" X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0660734671==" Errors-To: ldapext-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0660734671== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030601090102000405070207" This is a cryptographically signed message in MIME format. --------------ms030601090102000405070207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pierangelo Masarati wrote: >> Hmmm. I didn't think the control was required to be marked 'critical' >> > > from > > The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality may > be TRUE or FALSE. There is no controlValue. > > > >> but, if it is, then you are correct that the control will have been >> recognised if the request was performed. (Your remark "when the control >> is not critical" makes me believe that you don't understand the use of >> the criticality flag. For example, you cannot respond with >> "unavailableCriticalExtension" if the control is not marked critical.) >> > > I believe I understand it. That's why I agree that if no criticality was > set in the request, a control response with no value should be sent to > clarify that the DSA understood the control. > > If the client needs to know that there support for the control, doing so by altering the flow of the protocol is not the way to do it, particularly when the change in flow is unrelated to the mechanism that caused it. The client should examine the root DSE entry for supported controls, and should be able to expect the same behavior whether it marks the control critical or not. Marking a control non-critical implies a level of indifference as to whether its function is understood and performed and I fail to see the need to inform those who are indifferent. -- Pete --------------ms030601090102000405070207 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBzCC At4wggJHoAMCAQICEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oX DTA2MTIxODAxMzE1M1owRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8G CSqGSIb3DQEJARYScHJvd2xleUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAz5qzj9DVTZ6HS76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FW pszLXfKUgYnLBqgXXaSN7+Ve1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1 gLOjF6Yze9cHpio66W9orNdf1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55 j+Oj9+xGHeHK4lI96ljkWhTdgVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwup adY+BFiwBJRVMUTHlgSC99RJBgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQAB oy8wLTAdBgNVHREEFjAUgRJwcm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQCcnTFjF+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkz D3HLJYXu/9H1ltmXtDJMtOw/U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvks HDyJmWz1CvXmKzVHXnSaeK21vR/TKV3Z2Zu/7bXQGtRMmzCCAt4wggJHoAMCAQICEA20YTBn SYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oXDTA2MTIxODAxMzE1M1owRDEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScHJvd2xl eUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz5qzj9DVTZ6H S76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FWpszLXfKUgYnLBqgXXaSN7+Ve 1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1gLOjF6Yze9cHpio66W9orNdf 1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55j+Oj9+xGHeHK4lI96ljkWhTd gVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwupadY+BFiwBJRVMUTHlgSC99RJ BgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQABoy8wLTAdBgNVHREEFjAUgRJw cm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCcnTFj F+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkzD3HLJYXu/9H1ltmXtDJMtOw/ U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvksHDyJmWz1CvXmKzVHXnSaeK21 vR/TKV3Z2Zu/7bXQGtRMmzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQDbRhMGdJ hVdHgcD8KrKxXjAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wNjA1MDgyMzAzMzFaMCMGCSqGSIb3DQEJBDEWBBSXwiWmlV1CmnyM rKiNWLbFFpcc1jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEAqFOC+0fX4/62bOraODhvOsBps1Cw/aiuZoaYMtA7tptOtEmM5365nUFIX0La 1bYR6cXtiVcy3Gz13nyaf9iq7x8sJ6fmtQznuVfVgkB1Z1t7goZPJYfpnV2zX1NFYiRkztj7 rkt8ZJmuJJ10Yv0ojsTci4XeEZLKhx9/9tKM0RtPwbFkt9R6ErVJun1BuqBj2bhqfGDDh3pu Ka6kaehCpZs1pcp8JPKoTvtnECgXMbtjnen4znCjHirN10X3yybqhjodPI6MO6a1O5/lfIzE kf4HjYd8SLQLE2xuurKzhE/VyQkuosONIeoz2NBvr3e6Ln7V+Sod+UvRLS6W/bPgagAAAAAA AA== --------------ms030601090102000405070207-- --===============0660734671== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0660734671==-- From ldapext-bounces@ietf.org Mon May 08 19:40:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdFKW-0001bN-MM; Mon, 08 May 2006 19:39:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdFKV-0001ad-Cj for ldapext@ietf.org; Mon, 08 May 2006 19:39:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdFKV-0000Ye-BE for ldapext@ietf.org; Mon, 08 May 2006 19:39:55 -0400 Received: from boole.openldap.org ([204.152.186.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FdF3M-0006D6-Fo for ldapext@ietf.org; Mon, 08 May 2006 19:22:14 -0400 Received: from gypsy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k48NK9KU050454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 May 2006 23:20:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.1.0.0.20060508161240.03a47b98@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 08 May 2006 16:19:51 -0700 To: Pete Rowley From: "Kurt D. Zeilenga" Subject: Re: [ldapext] password policy response control question In-Reply-To: <445FCE43.3070307@redhat.com> References: <33821.131.175.154.56.1147076220.squirrel@131.175.154.56> <52681ACFF63C114F8A3C3651FC9D301F26B175@AUSYMS11.ca.com> <34131.131.175.154.56.1147082584.squirrel@131.175.154.56> <445FCE43.3070307@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -2.6 (--) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "Ramsay, Ron" , ldapext@ietf.org, John McMeeking X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org A control can be recognized by the server and hence published in supportedControl but current unavailable. I also note that supportedControl may be visible to the client. But I think this is a bit of digression. IMO, If a request control has an associated response control, that response control should be returned whenever the request control is made use of in processing the operation. No exceptions. Having a request control that sometimes has, sometimes hasn't a response control is bad. Kurt At 04:03 PM 5/8/2006, Pete Rowley wrote: >Pierangelo Masarati wrote: >>>Hmmm. I didn't think the control was required to be marked 'critical' >>> >> >>from >> >> The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality may >> be TRUE or FALSE. There is no controlValue. >> >> >> >>>but, if it is, then you are correct that the control will have been >>>recognised if the request was performed. (Your remark "when the control >>>is not critical" makes me believe that you don't understand the use of >>>the criticality flag. For example, you cannot respond with >>>"unavailableCriticalExtension" if the control is not marked critical.) >>> >> >>I believe I understand it. That's why I agree that if no criticality was >>set in the request, a control response with no value should be sent to >>clarify that the DSA understood the control. >> >> >If the client needs to know that there support for the control, doing so by altering the flow of the protocol is not the way to do it, particularly when the change in flow is unrelated to the mechanism that caused it. The client should examine the root DSE entry for supported controls, and should be able to expect the same behavior whether it marks the control critical or not. Marking a control non-critical implies a level of indifference as to whether its function is understood and performed and I fail to see the need to inform those who are indifferent. > >-- >Pete > > > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed May 10 02:31:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdiDp-0001z8-7J; Wed, 10 May 2006 02:30:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdi99-0001P8-Fs for ldapext@ietf.org; Wed, 10 May 2006 02:26:07 -0400 Received: from [72.232.34.10] (helo=host.eb2bcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdhwb-0003pg-Sx for ldapext@ietf.org; Wed, 10 May 2006 02:13:11 -0400 Received: from [203.206.165.210] (helo=[192.168.1.158]) by host.eb2bcom.com with esmtpa (Exim 4.52) id 1FdhwX-00029I-9W; Wed, 10 May 2006 16:13:05 +1000 Message-ID: <4461846B.4030105@eB2Bcom.com> Date: Wed, 10 May 2006 16:12:59 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Ldapext , hyc@symas.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.eb2bcom.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - eB2Bcom.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Subject: [ldapext] Comments: draft-chu-ldap-xordered-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew.sciberras@eB2Bcom.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Hi Howard, I am curious as to what the intended publication status of this draft will be (i.e. experimental, informational, etc)? I would have concerns about the proposed strategy if this was a Standards Track document. The main concerns that I have about the draft in its current form are that: 1. *Values that do not conform to the syntax* I agree with your statement in 2.2 that: "Using this extension on an attribute requires that ordering-prefix is a legal value of the LDAP syntax of that attribute." This statement is broken for Ordering Siblings and EXAMPLE_AT.2. A Distinguished Name is not allowed to start with a curly brace '{'. 2. Which attributes can use this extension? The following statement is present in section 3.1: " In general this extension is only compatible with AttributeTypes that have a string-oriented syntax." I think that we need to be more specific about the syntaxes that can use this functionality. I would be inclined to restrict it to Directory String, IA5 String and Octet String . 3. Interoperability Problems This functionality will cause severe problems between client and server interoperability. A likely case that can exist, is when we have a server that implements x-ordering, and a client that doesn't. When the client gets results back, it will most likely reject (or fail to decode) any DN value that contains ordering information. Any values that are returned with ordering information will be treated as-is. This will cause the ordering information to be treated as part of the attribute value, which may cause problems with the client. I cannot see any way of informing an unaware client that the ordering data in the value have special semantics. A bigger problem is that a client cannot indicate that they don't want additional ordering information prepended to values. An x-ordering aware client, who doesn't care about ordering, will need to read schema and identify which attributes have been subjected to ordering data, and then remove it. 4. Modification of AttributeTypeDescription is inappropriate and incomplete. Section 3.1 states: " The "X-ORDERED" schema extension is added to an AttributeTypeDescription to signify the use of this ordering mechanism." Whilst this is acceptable in LDAP, the X- extension is intended for private extensions and should not be standardized. The consequence of updating the Attribute Type Description in a doc like this is that any LDAP server that supports this extension will not be able to encode the value in any encoding other than the LDAP specific string encoding (i.e. you wont be able to BER or GSER encode an attributeTypeDescription value). 5. Security Considerations Security consideration should include additional information. The x-ordering semantics could be used for retaining a password history by simply adding values to the {0} position and only looking at the first x values. The problem here is that this draft is changing the semantics of matching rules (and the semantics of the absence of matching rules) by permitting assertions to be made only on ordering information. This could lead to the disclosure of information, without the client being required to know anything about the values it holds. 6. Matching Semantics The document doesn't indicate how ordering-prefixes should be matched. My common sense tells me that {0} is equal to {00} and {01} is equal to {1}, but the I-D should explicitly state whether we're comparing integers or strings. I think that a better implementation of this functionality would ensure that the functionality is only exercised if the client supports the functionality and it requests its usage. I think its pointless advertising a feature which indicates an uncontrollable change in the semantics of the protocol, as clients should refuse to work with any LDAP server that contains unknown features since they cannot establish how the protocol has changed. Possibly the solution should incorporate the usage of controls or ldap attribute options. Cheers, -- Andrew Sciberras, CISSP Solution Architect eB2Bcom Pty Ltd _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed May 10 04:21:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdjvz-0004Er-6t; Wed, 10 May 2006 04:20:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdjvx-0004Em-Je for ldapext@ietf.org; Wed, 10 May 2006 04:20:37 -0400 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdjvv-00012R-43 for ldapext@ietf.org; Wed, 10 May 2006 04:20:37 -0400 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id k4A8KOuP010764; Wed, 10 May 2006 03:20:25 -0500 Message-ID: <4461A24B.70203@highlandsun.com> Date: Wed, 10 May 2006 01:20:27 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060427 SeaMonkey/1.5a MIME-Version: 1.0 To: andrew.sciberras@eB2Bcom.com Subject: Re: [ldapext] Comments: draft-chu-ldap-xordered-00.txt References: <4461846B.4030105@eB2Bcom.com> In-Reply-To: <4461846B.4030105@eB2Bcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Andrew Sciberras wrote: > Hi Howard, > > I am curious as to what the intended publication status of this draft > will be (i.e. experimental, informational, etc)? Hi Andrew, thanks for the feedback. This draft is intended to be published as Informational only. It was supposed to reflect what we've been using in OpenLDAP for the past several months to provide ordering for attributes in our server config DIT, but things have already diverged in the intervening time. On the off chance that other implementors would want to adopt this approach, it would make sense to fix this up. > I would have concerns about the proposed strategy if this was a > Standards Track document. > The main concerns that I have about the draft in its current form are that: > > 1. *Values that do not conform to the syntax* > I agree with your statement in 2.2 that: > "Using this extension on an attribute requires that ordering-prefix is a > legal value of the LDAP syntax of that attribute." > > This statement is broken for Ordering Siblings and EXAMPLE_AT.2. A > Distinguished Name is not allowed to start with a curly brace '{'. > > 2. Which attributes can use this extension? > The following statement is present in section 3.1: > " In general this extension is only compatible with AttributeTypes that > have a string-oriented syntax." > > I think that we need to be more specific about the syntaxes that can use > this functionality. I would be inclined to restrict it to Directory > String, IA5 String and Octet String . Yes, these are both good points; I think I was hedging a bit too much when I wrote those statements. The actual implementation in OpenLDAP strips the prefix before dropping into the underlying syntax's validators/normalizers, so it actually works for any syntax. The extension wouldn't be as useful if it was limited to only a few syntaxes; I'll have to come up with some new language here. > 3. Interoperability Problems > This functionality will cause severe problems between client and server > interoperability. A likely case that can exist, is when we have a server > that implements x-ordering, and a client that doesn't. > When the client gets results back, it will most likely reject (or fail > to decode) any DN value that contains ordering information. Any values > that are returned with ordering information will be treated as-is. This > will cause the ordering information to be treated as part of the > attribute value, which may cause problems with the client. > I cannot see any way of informing an unaware client that the ordering > data in the value have special semantics. > > A bigger problem is that a client cannot indicate that they don't want > additional ordering information prepended to values. An x-ordering aware > client, who doesn't care about ordering, will need to read schema and > identify which attributes have been subjected to ordering data, and then > remove it. Perhaps we should investigate use of a control, as you suggested in (6). Part of the rationale for making the prefix always present was so that it would be transported along with the data when passing through unaware agents. The idea being that even a server that didn't support the extension could store the data, and even if it returned values in arbitrary order, an aware client could sort it back into the intended order. But obviously that only works when the prefix is legal for the syntax, which brings us back to your (1) and (2). > 4. Modification of AttributeTypeDescription is inappropriate and > incomplete. > Section 3.1 states: > " The "X-ORDERED" schema extension is added to an > AttributeTypeDescription to signify the use of this ordering mechanism." > > Whilst this is acceptable in LDAP, the X- extension is intended for > private extensions and should not be standardized. The consequence of > updating the Attribute Type Description in a doc like this is that any > LDAP server that supports this extension will not be able to encode the > value in any encoding other than the LDAP specific string encoding (i.e. > you wont be able to BER or GSER encode an attributeTypeDescription value). That probably should have been "AttributeType definition"; we definitely are not passing the extension string around on attributeType descriptions in protocol transactions. > 5. Security Considerations > Security consideration should include additional information. The > x-ordering semantics could be used for retaining a password history by > simply adding values to the {0} position and only looking at the first x > values. The problem here is that this draft is changing the semantics of > matching rules (and the semantics of the absence of matching rules) by > permitting assertions to be made only on ordering information. This > could lead to the disclosure of information, without the client being > required to know anything about the values it holds. I'll add a note to that effect. This capability is already called out at the end of section 4.2. I saw it as an asset not a liability, but I see your point. > 6. Matching Semantics > The document doesn't indicate how ordering-prefixes should be matched. > My common sense tells me that {0} is equal to {00} and {01} is equal to > {1}, but the I-D should explicitly state whether we're comparing > integers or strings. Yes, integers. I'll add an explicit statement for this. > I think that a better implementation of this functionality would ensure > that the functionality is only exercised if the client supports the > functionality and it requests its usage. I think its pointless > advertising a feature which indicates an uncontrollable change in the > semantics of the protocol, as clients should refuse to work with any > LDAP server that contains unknown features since they cannot establish > how the protocol has changed. > > Possibly the solution should incorporate the usage of controls or ldap > attribute options. > > Cheers, > Thanks again, you've reminded me there's a lot more to think about still. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri May 12 10:00:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeYBe-0004gy-IJ; Fri, 12 May 2006 10:00:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeYB3-0004VA-UB for ldapext@ietf.org; Fri, 12 May 2006 09:59:33 -0400 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeYB1-0006Le-HD for ldapext@ietf.org; Fri, 12 May 2006 09:59:33 -0400 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id k4CDx1EB009107; Fri, 12 May 2006 08:59:12 -0500 Message-ID: <446494AC.5090605@highlandsun.com> Date: Fri, 12 May 2006 06:59:08 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060427 SeaMonkey/1.5a MIME-Version: 1.0 To: andrew.sciberras@eB2Bcom.com Subject: Re: [ldapext] Comments: draft-chu-ldap-xordered-00.txt References: <4461846B.4030105@eB2Bcom.com> In-Reply-To: <4461846B.4030105@eB2Bcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Another pass. Andrew Sciberras wrote: > Hi Howard, > > I am curious as to what the intended publication status of this draft > will be (i.e. experimental, informational, etc)? Informational. > I would have concerns about the proposed strategy if this was a > Standards Track document. > The main concerns that I have about the draft in its current form are that: > > 1. *Values that do not conform to the syntax* > I agree with your statement in 2.2 that: > "Using this extension on an attribute requires that ordering-prefix is a > legal value of the LDAP syntax of that attribute." > > This statement is broken for Ordering Siblings and EXAMPLE_AT.2. A > Distinguished Name is not allowed to start with a curly brace '{'. Actually Ordered Siblings is fine since the prefix precedes the RDN value, not the RDN type. > 3. Interoperability Problems > This functionality will cause severe problems between client and server > interoperability. A likely case that can exist, is when we have a server > that implements x-ordering, and a client that doesn't. > When the client gets results back, it will most likely reject (or fail > to decode) any DN value that contains ordering information. Any values > that are returned with ordering information will be treated as-is. This > will cause the ordering information to be treated as part of the > attribute value, which may cause problems with the client. > I cannot see any way of informing an unaware client that the ordering > data in the value have special semantics. > > A bigger problem is that a client cannot indicate that they don't want > additional ordering information prepended to values. An x-ordering aware > client, who doesn't care about ordering, will need to read schema and > identify which attributes have been subjected to ordering data, and then > remove it. As I see it there are three possible outcomes: 1) the client is totally unaware of schema - in this case the client treats everything as blobs, and doesn't care. 2) the client is schema-aware, but doesn't recognize the x-ordering schema extension - in this case, the client should probably treat the attribute as unrecognized. It seems that the ldapbis-models doc doesn't really address what to do about unrecognized extensions. 3) the client is schema-aware and recognizes the schema extension - then it should just deal with it. I.e., it is as much a property of the attribute as "numericString may only contain digits 0-9". > 4. Modification of AttributeTypeDescription is inappropriate and > incomplete. > Section 3.1 states: > " The "X-ORDERED" schema extension is added to an > AttributeTypeDescription to signify the use of this ordering mechanism." > > Whilst this is acceptable in LDAP, the X- extension is intended for > private extensions and should not be standardized. The consequence of > updating the Attribute Type Description in a doc like this is that any > LDAP server that supports this extension will not be able to encode the > value in any encoding other than the LDAP specific string encoding (i.e. > you wont be able to BER or GSER encode an attributeTypeDescription value). I obviously misunderstood you the last time around. The original goal here was not standards track, thus the X- extension. If there's sufficient interest in a generally usable ordering feature, then we can explore that path. Looking at the current BCP64 draft, there's no procedure for registering new schema definition elements. > > I think that a better implementation of this functionality would ensure > that the functionality is only exercised if the client supports the > functionality and it requests its usage. I think its pointless > advertising a feature which indicates an uncontrollable change in the > semantics of the protocol, as clients should refuse to work with any > LDAP server that contains unknown features since they cannot establish > how the protocol has changed. > > Possibly the solution should incorporate the usage of controls or ldap > attribute options. The use of attribute options was another possibility that we'd considered in the past. It's awkward, since items with different tagging options are actually separate attributes. E.g. attr-foo;x-order0: first value attr-foo;x-order1: second value It also does not give a client the choice to use the feature or not. Also it precludes the Ordered Siblings capability, since attributes in RDNs cannot have any options. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed May 17 22:28:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgYEW-00081z-1y; Wed, 17 May 2006 22:27:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgYEV-00081u-Bi for ldapext@ietf.org; Wed, 17 May 2006 22:27:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgY5l-0000pk-RD for ldapext@ietf.org; Wed, 17 May 2006 22:18:21 -0400 Received: from [72.232.34.10] (helo=host.eb2bcom.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FgXog-0004ls-49 for ldapext@ietf.org; Wed, 17 May 2006 22:00:44 -0400 Received: from [203.206.165.210] (helo=ASCRIBBLER) by host.eb2bcom.com with esmtpa (Exim 4.52) id 1FgXoe-00082L-PN; Thu, 18 May 2006 12:00:41 +1000 From: To: "'Howard Chu'" Subject: RE: [ldapext] Comments: draft-chu-ldap-xordered-00.txt Date: Thu, 18 May 2006 12:00:42 +1000 Organization: eB2Bcom MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <446494AC.5090605@highlandsun.com> Thread-Index: AcZ1zEzdl5aJ9n7XSdSZNQbk5I+6QQEUnoKg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.eb2bcom.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - eb2bcom.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.6 (--) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: 'Ldapext' X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew.sciberras@eb2bcom.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Message-Id: Hi Howard, Thanks for your feedback. See my responses below: > -----Original Message----- > From: Howard Chu [mailto:hyc@highlandsun.com] > Sent: Friday, 12 May 2006 11:59 PM > To: andrew.sciberras@eB2Bcom.com > Cc: Ldapext > Subject: Re: [ldapext] Comments: draft-chu-ldap-xordered-00.txt > > Another pass. > > Andrew Sciberras wrote: > > 1. *Values that do not conform to the syntax* > > I agree with your statement in 2.2 that: > > "Using this extension on an attribute requires that > ordering-prefix is a > > legal value of the LDAP syntax of that attribute." > > > > This statement is broken for Ordering Siblings and EXAMPLE_AT.2. A > > Distinguished Name is not allowed to start with a curly brace '{'. > > Actually Ordered Siblings is fine since the prefix precedes the RDN > value, not the RDN type. That's right.. A silly oversight by me. Ordered Siblings is fine, whilst the distinguishedName attribute olcSuffix still break the DN syntax. > > > 3. Interoperability Problems > > This functionality will cause severe problems between > client and server > > interoperability. A likely case that can exist, is when we > have a server > > that implements x-ordering, and a client that doesn't. > > When the client gets results back, it will most likely > reject (or fail > > to decode) any DN value that contains ordering information. > Any values > > that are returned with ordering information will be treated > as-is. This > > will cause the ordering information to be treated as part of the > > attribute value, which may cause problems with the client. > > I cannot see any way of informing an unaware client that > the ordering > > data in the value have special semantics. > > > > A bigger problem is that a client cannot indicate that they > don't want > > additional ordering information prepended to values. An > x-ordering aware > > client, who doesn't care about ordering, will need to read > schema and > > identify which attributes have been subjected to ordering > data, and then > > remove it. > > As I see it there are three possible outcomes: > 1) the client is totally unaware of schema - in this case > the client > treats everything as blobs, and doesn't care. Ok, this sounds reasonable to me. > 2) the client is schema-aware, but doesn't recognize the > x-ordering > schema extension - in this case, the client should probably treat the > attribute as unrecognized. It seems that the ldapbis-models > doc doesn't > really address what to do about unrecognized extensions. I would imagine that the handling of private extensions to well defined schema elements and attribute type definitions should be implemented in a way that they can be ignored if unrecognised. This relies on the private extension not changing the semantics of the protocol though. Model's isn't explicit about how clients and severs should handle unrecognised extensions, but it does state: - extensions to schema elements must start with "X-" - Anything starting with "X-" are reserved for private experiments This leads me to think that any schema extensions are for private use only and cannot be standardised, which is possibly why BCP doesn't allow for extensions to be registered. It's obviously fine in this case, since the draft is Informational and can be perceived as providing information about a private extension used in an existing implementation. I think the problem is that clients that do not support the extension, should not be delivered information that has been modified for the purpose of the extension. > > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc > OpenLDAP Core Team http://www.openldap.org/project/ Andrew Sciberras eB2Bcom _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed May 17 22:34:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgYL8-00024d-Op; Wed, 17 May 2006 22:34:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgYL7-00024Y-Qm for ldapext@ietf.org; Wed, 17 May 2006 22:34:13 -0400 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgYL7-0002Bu-G2 for ldapext@ietf.org; Wed, 17 May 2006 22:34:13 -0400 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id k4I2Xv7j002973; Wed, 17 May 2006 21:33:58 -0500 Message-ID: <446BDD13.7010308@highlandsun.com> Date: Wed, 17 May 2006 19:33:55 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060512 SeaMonkey/1.5a MIME-Version: 1.0 To: andrew.sciberras@eb2bcom.com Subject: Re: [ldapext] Comments: draft-chu-ldap-xordered-00.txt References: <200605180201.k4I20qVm002393@highlandsun.propagation.net> In-Reply-To: <200605180201.k4I20qVm002393@highlandsun.propagation.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: 'Ldapext' X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org andrew.sciberras@eb2bcom.com wrote: > Hi Howard, > > Thanks for your feedback. > > See my responses below: > > That's right.. A silly oversight by me. Ordered Siblings is fine, whilst the > distinguishedName attribute olcSuffix still break the DN syntax. For the moment, I think we're going to have live with this. E.g., I can define "the ordering-prefix is ignored when validating that a value conforms to an attribute's syntax" but that doesn't address the interoperability issue. >> 2) the client is schema-aware, but doesn't recognize the >> x-ordering >> schema extension - in this case, the client should probably treat the >> attribute as unrecognized. It seems that the ldapbis-models >> doc doesn't >> really address what to do about unrecognized extensions. > > I would imagine that the handling of private extensions to well defined > schema elements and attribute type definitions should be implemented in a > way that they can be ignored if unrecognised. This relies on the private > extension not changing the semantics of the protocol though. > > Model's isn't explicit about how clients and severs should handle > unrecognised extensions, but it does state: > - extensions to schema elements must start with "X-" > - Anything starting with "X-" are reserved for private experiments > > This leads me to think that any schema extensions are for private use only > and cannot be standardised, which is possibly why BCP doesn't allow for > extensions to be registered. It's obviously fine in this case, since the > draft is Informational and can be perceived as providing information about a > private extension used in an existing implementation. OK > I think the problem is > that clients that do not support the extension, should not be delivered > information that has been modified for the purpose of the extension. It was suggested that the ordering-prefix should be omitted from search responses unless explicitly requested (by a control) but there are situations where I don't think it makes sense when omitted. E.g., if I have multiple hdb databases in my server configuration, I want ldapsearch to return: dn: olcDatabase={1}hdb,cn=config dn: olcDatabase={2}hdb,cn=config dn: olcDatabase={3}hdb,cn=config whether the client understands the X-ORDERED 'SIBLINGS' extension or not, otherwise the search responses make no sense (cannot be disambiguated). -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext