From ldapext-admin@ietf.org Tue Mar 2 04:27:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28961 for ; Tue, 2 Mar 2004 04:27:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay6B2-0003ZV-GO; Tue, 02 Mar 2004 04:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay6AN-0003Xb-E3 for ldapext@optimus.ietf.org; Tue, 02 Mar 2004 04:26:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28879 for ; Tue, 2 Mar 2004 04:26:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay6AK-000608-00 for ldapext@ietf.org; Tue, 02 Mar 2004 04:26:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay69M-0005sL-00 for ldapext@ietf.org; Tue, 02 Mar 2004 04:25:17 -0500 Received: from du-006-006.access.de.clara.net ([212.82.229.6] helo=nb2.stroeder.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay68Q-0005az-00 for ldapext@ietf.org; Tue, 02 Mar 2004 04:24:19 -0500 Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 6AF907A3DA; Mon, 1 Mar 2004 18:55:55 +0100 (CET) Message-ID: <4043792A.5000809@stroeder.com> Date: Mon, 01 Mar 2004 18:55:54 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: John McMeeking Cc: "Ldapext (E-mail)" Subject: Re: [ldapext] RE:draft-behera-ldap-password-policy-07.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit John McMeeking wrote: > > There are cases where password changes are processed through an > applicatiuon that runs under some administrative identity; the user does > not have authority to change his entry directly. I believe password policy > should still apply in such cases and behave much like the user was changing > his own password. I think the application accessing the user's entry under some administrative identity should enforce all the password rules then. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 2 05:14:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28962 for ; Tue, 2 Mar 2004 04:27:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay6B3-0003Zd-3o; Tue, 02 Mar 2004 04:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay6AO-0003Xg-1P for ldapext@optimus.ietf.org; Tue, 02 Mar 2004 04:26:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28882 for ; Tue, 2 Mar 2004 04:26:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay6AL-00060D-00 for ldapext@ietf.org; Tue, 02 Mar 2004 04:26:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay69N-0005sT-00 for ldapext@ietf.org; Tue, 02 Mar 2004 04:25:17 -0500 Received: from du-006-006.access.de.clara.net ([212.82.229.6] helo=nb2.stroeder.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay68Q-0005bA-00 for ldapext@ietf.org; Tue, 02 Mar 2004 04:24:19 -0500 Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 729A858FBF; Mon, 1 Mar 2004 18:52:50 +0100 (CET) Message-ID: <40437871.5010009@stroeder.com> Date: Mon, 01 Mar 2004 18:52:49 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: andrew.sciberras@adacel.com Cc: "Ldapext (E-mail)" Subject: Re: [ldapext] RE:draft-behera-ldap-password-policy-07.txt References: <038b01c3f686$ab87f350$a618200a@mtwav.adacel.com.au> In-Reply-To: <038b01c3f686$ab87f350$a618200a@mtwav.adacel.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Andrew Sciberras wrote: > > Section 6.1.2B (Page 20) > >>If the number of these failures is greater or equal to the >>pwdMaxFailure attribute, the server MUST lock the account >>by setting the value of the pwdAccountLockedTime attribute >>to the current time. After locking the account, the server >>MUST send a bindResponse to the client with the >>resultCode: unwillingToPerform (53), and MUST include the >>passwordPolicyResponse in the controls field of the >>bindResponse message with the error: accountLocked (1). > > > I do not think that the return code should be unwillingToPerform. In this > scenario, the user has got their password wrong and this incorrect > attempt has made the number of failures exceed the pwdMaxFailure limit. > In this case the reason why the operation (BIND) is going to fail is > because of the incorrect password. The fact that the number of bind > failures has exceeded a policy limit is just a consequence of that. For > this reason I believe that the resultCode should be invalidCredentials. Andrew, I understand the rationale of your argument but I'd like to see a different error code returned for LDAP applications which are not aware of draft-behera-ldap-password-policy. unwillingToPerform would somewhat indicate a final failure whereas invalidCredentials makes the LDAP client just pop-up another login window... Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 2 12:10:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19737 for ; Tue, 2 Mar 2004 12:10:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyDP9-0001R2-3X; Tue, 02 Mar 2004 12:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyDOD-0001Lw-IK for ldapext@optimus.ietf.org; Tue, 02 Mar 2004 12:09:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19643 for ; Tue, 2 Mar 2004 12:09:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyDOB-0004Lv-00 for ldapext@ietf.org; Tue, 02 Mar 2004 12:09:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyDN6-0004CD-00 for ldapext@ietf.org; Tue, 02 Mar 2004 12:07:56 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx with esmtp (Exim 4.12) id 1AyDMf-00043w-00 for ldapext@ietf.org; Tue, 02 Mar 2004 12:07:29 -0500 Received: from CELLO (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.12.9/8.12.9) with SMTP id i22H7QU0012864 for ; Tue, 2 Mar 2004 11:07:26 -0600 From: "Howard Chu" To: Subject: Re: [ldapext] RE:draft-behera-ldap-password-policy-07.txt Date: Tue, 2 Mar 2004 09:07:06 -0800 Message-ID: <00a901c40078$d07b8d10$1801a8c0@CELLO> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040302170006.28184.70370.Mailman@www1.ietf.org> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > From: =?ISO-8859-1?Q?Michael_Str=F6der?= > Andrew Sciberras wrote: > > > > Section 6.1.2B (Page 20) > > > >>If the number of these failures is greater or equal to the > >>pwdMaxFailure attribute, the server MUST lock the account > >>by setting the value of the pwdAccountLockedTime attribute > >>to the current time. After locking the account, the server > >>MUST send a bindResponse to the client with the > >>resultCode: unwillingToPerform (53), and MUST include the > >>passwordPolicyResponse in the controls field of the > >>bindResponse message with the error: accountLocked (1). > > > > > > I do not think that the return code should be > unwillingToPerform. In this > > scenario, the user has got their password wrong and this incorrect > > attempt has made the number of failures exceed the > pwdMaxFailure limit. > > In this case the reason why the operation (BIND) is going to fail is > > because of the incorrect password. The fact that the number of bind > > failures has exceeded a policy limit is just a consequence > of that. For > > this reason I believe that the resultCode should be > invalidCredentials. > > Andrew, I understand the rationale of your argument but I'd > like to see a > different error code returned for LDAP applications which are > not aware of > draft-behera-ldap-password-policy. unwillingToPerform would somewhat > indicate a final failure whereas invalidCredentials makes the > LDAP client > just pop-up another login window... >From a purist's security perspective, I'd agree that invalidCredentials is the correct response. One of the maxims in security is to provide the minimal amount of information to an attacker. Thus, one is advised to avoid giving responses that differentiate between "account does not exist" / "password is incorrect" / "account locked due to too many failed attempts" ... Following this argument, I wouldn't even provide any special information in the passwordPolicyResponse control. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 2 19:10:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11583 for ; Tue, 2 Mar 2004 19:10:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJxY-00050i-W3; Tue, 02 Mar 2004 19:10:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJwa-0004i9-8p for ldapext@optimus.ietf.org; Tue, 02 Mar 2004 19:09:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11519 for ; Tue, 2 Mar 2004 19:08:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyJwW-0001Ns-00 for ldapext@ietf.org; Tue, 02 Mar 2004 19:08:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyJvd-0001Fy-00 for ldapext@ietf.org; Tue, 02 Mar 2004 19:08:02 -0500 Received: from mail17.ca.com ([155.35.248.106] helo=ausyms50.ca.com) by ietf-mx with esmtp (Exim 4.12) id 1AyJuo-0000xk-00 for ldapext@ietf.org; Tue, 02 Mar 2004 19:07:10 -0500 Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Mar 2004 11:06:39 +1100 x-mimeole: Produced By Microsoft Exchange V6.0.6547.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] RE:draft-behera-ldap-password-policy-07.txt Date: Wed, 3 Mar 2004 11:06:39 +1100 Message-ID: <1395B4B334FCC143B36AF788E68B6381011B3D29@ausyms21.ca.com> Thread-Topic: [ldapext] RE:draft-behera-ldap-password-policy-07.txt Thread-Index: AcQAOKDgdIawVKjBQ6mDnPRy0CGnfAAeoQGg From: "Ramsay, Ron" To: =?iso-8859-1?Q?Michael_Str=F6der?= Cc: "Ldapext \(E-mail\)" X-OriginalArrivalTime: 03 Mar 2004 00:06:39.0234 (UTC) FILETIME=[6684C620:01C400B3] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Don't change the LDAP protocol - just DON'T. If you use the control, you = have some leeway, but without the control you MUST defer to RFC 2251. Ron -----Original Message----- From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org]On Behalf Of Michael Str=F6der Sent: Tuesday, 2 March 2004 04:53 To: andrew.sciberras@adacel.com Cc: Ldapext (E-mail) Subject: Re: [ldapext] RE:draft-behera-ldap-password-policy-07.txt Andrew Sciberras wrote: > > Section 6.1.2B (Page 20) > >>If the number of these failures is greater or equal to the >>pwdMaxFailure attribute, the server MUST lock the account >>by setting the value of the pwdAccountLockedTime attribute >>to the current time. After locking the account, the server >>MUST send a bindResponse to the client with the >>resultCode: unwillingToPerform (53), and MUST include the >>passwordPolicyResponse in the controls field of the >>bindResponse message with the error: accountLocked (1). > > > I do not think that the return code should be unwillingToPerform. In = this > scenario, the user has got their password wrong and this incorrect > attempt has made the number of failures exceed the pwdMaxFailure = limit. > In this case the reason why the operation (BIND) is going to fail is > because of the incorrect password. The fact that the number of bind > failures has exceeded a policy limit is just a consequence of that. = For > this reason I believe that the resultCode should be = invalidCredentials. Andrew, I understand the rationale of your argument but I'd like to see = a=20 different error code returned for LDAP applications which are not aware = of=20 draft-behera-ldap-password-policy. unwillingToPerform would somewhat=20 indicate a final failure whereas invalidCredentials makes the LDAP = client=20 just pop-up another login window... Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 2 21:10:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20791 for ; Tue, 2 Mar 2004 21:10:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLph-0007xf-2x; Tue, 02 Mar 2004 21:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLon-0007vn-Ji for ldapext@optimus.ietf.org; Tue, 02 Mar 2004 21:09:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20734 for ; Tue, 2 Mar 2004 21:09:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLol-0005Ia-00 for ldapext@ietf.org; Tue, 02 Mar 2004 21:09:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLnp-0005AY-00 for ldapext@ietf.org; Tue, 02 Mar 2004 21:08:06 -0500 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1AyLnM-00051h-00 for ldapext@ietf.org; Tue, 02 Mar 2004 21:07:36 -0500 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.5.9) id ; Wed, 03 Mar 2004 12:58:05 +1100 Received: (qmail 12118 invoked from network); 3 Mar 2004 02:07:04 -0000 Received: from unknown (HELO shylock) (10.32.24.166) by nexus.adacel.com with SMTP; 3 Mar 2004 02:07:04 -0000 Reply-To: From: "Andrew Sciberras" To: "'Howard Chu'" Cc: "Ldapext \(E-mail\)" Subject: RE: [ldapext] RE:draft-behera-ldap-password-policy-07.txt Date: Wed, 3 Mar 2004 13:07:02 +1100 Message-ID: <008a01c400c4$390586b0$a618200a@mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <00a901c40078$d07b8d10$1801a8c0@CELLO> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >-----Original Message----- >From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org]On >Behalf Of >Howard Chu >Sent: Wednesday, 3 March 2004 4:07 >To: ldapext@ietf.org >Subject: Re: [ldapext] RE:draft-behera-ldap-password-policy-07.txt >... Following >this argument, I wouldn't even provide any special information in the >passwordPolicyResponse control. > Bringing us back to the question: When is the password policy control returned? * Always, or * Every time important information needs to be conveyed, or * Only for specific operations as stated in section 5.2 * Only for specific operations as stated in section 5.2 and important information must be conveyed, or * When the operation has succeeded/failed due to the password policy regardless of the operation and whether we have important information to convey. (The above list is based on the fact that the client has provided a request control) Cheers, Andrew Sciberras. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Mar 3 01:43:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06248 for ; Wed, 3 Mar 2004 01:43:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQ5t-0001TX-82; Wed, 03 Mar 2004 01:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQ55-0001MK-VV for ldapext@optimus.ietf.org; Wed, 03 Mar 2004 01:42:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06214 for ; Wed, 3 Mar 2004 01:42:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQ52-0001GZ-00 for ldapext@ietf.org; Wed, 03 Mar 2004 01:42:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQ49-00019D-00 for ldapext@ietf.org; Wed, 03 Mar 2004 01:41:14 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx with esmtp (Exim 4.12) id 1AyQ3J-00011W-00 for ldapext@ietf.org; Wed, 03 Mar 2004 01:40:21 -0500 Received: from CELLO (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.12.9/8.12.9) with SMTP id i236eIY6027752 for ; Wed, 3 Mar 2004 00:40:18 -0600 From: "Howard Chu" To: "'Ldapext \(E-mail\)'" Subject: RE: [ldapext] RE:draft-behera-ldap-password-policy-07.txt Date: Tue, 2 Mar 2004 22:39:52 -0800 Message-ID: <00d501c400ea$5f799f90$1801a8c0@CELLO> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <008a01c400c4$390586b0$a618200a@mtwav.adacel.com.au> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Section 7 page 27, shouldn't this be: In the event that the passwordPolicyRequest control was not sent, no passwordPolicyResponse control is returned. ^^^^^^^^ -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Mar 3 01:51:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06535 for ; Wed, 3 Mar 2004 01:51:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQDe-0003Ne-JR; Wed, 03 Mar 2004 01:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQCs-0003G4-OL for ldapext@optimus.ietf.org; Wed, 03 Mar 2004 01:50:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06476 for ; Wed, 3 Mar 2004 01:50:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQCp-0002Fq-00 for ldapext@ietf.org; Wed, 03 Mar 2004 01:50:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQBs-00027s-00 for ldapext@ietf.org; Wed, 03 Mar 2004 01:49:12 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx with esmtp (Exim 4.12) id 1AyQBN-00020G-00 for ldapext@ietf.org; Wed, 03 Mar 2004 01:48:41 -0500 Received: from CELLO (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.12.9/8.12.9) with SMTP id i236mdY6027906 for ; Wed, 3 Mar 2004 00:48:39 -0600 From: "Howard Chu" To: Subject: RE: [ldapext] RE:draft-behera-ldap-password-policy-07.txt Date: Tue, 2 Mar 2004 22:48:14 -0800 Message-ID: <00d801c400eb$89e75410$1801a8c0@CELLO> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Section 6 page 17 (top) again: In the event that the passwordPolicyRequest control was not sent, no passwordPolicyResponse control is returned. ^^^^^^^^ > -----Original Message----- > From: Howard Chu [mailto:hyc@highlandsun.com] > From a purist's security perspective, I'd agree that > invalidCredentials is the correct response. One of the maxims > in security is to provide the minimal amount of information > to an attacker. Thus, one is advised to avoid giving > responses that differentiate between "account does not exist" > / "password is incorrect" / "account locked due to too many > failed attempts" ... Following this argument, I wouldn't even > provide any special information in the passwordPolicyResponse control. So I would change 6.1.1 If the account is locked, the server MUST send a bindResponse to the client with the resultCode: invalidCredentials (49). The server MAY set the error: accountLocked (1) in the passwordPolicyResponse in the controls field of the bindResponse message. I.e., I would like to leave it up to the admin to decide whether this error code should be returned or not. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Mar 3 02:09:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18377 for ; Wed, 3 Mar 2004 02:09:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQV4-0001HS-2Z; Wed, 03 Mar 2004 02:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQUP-0000wH-Cq for ldapext@optimus.ietf.org; Wed, 03 Mar 2004 02:08:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16859 for ; Wed, 3 Mar 2004 02:08:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQUL-0005hQ-00 for ldapext@ietf.org; Wed, 03 Mar 2004 02:08:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQT7-0005L1-00 for ldapext@ietf.org; Wed, 03 Mar 2004 02:07:02 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AyQRr-0004xh-00 for ldapext@ietf.org; Wed, 03 Mar 2004 02:05:43 -0500 Received: from odin.France.Sun.COM ([129.157.174.8]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i237570J010673; Tue, 2 Mar 2004 23:05:07 -0800 (PST) Received: from Sun.COM (vpn-129-150-116-10.UK.Sun.COM [129.150.116.10]) by odin.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id i23755P07433; Wed, 3 Mar 2004 08:05:05 +0100 (MET) Message-ID: <4045836B.3010001@Sun.COM> Date: Wed, 03 Mar 2004 08:04:11 +0100 From: Ludovic Poitou Organization: SUN Microsystems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Howard Chu CC: "'Ldapext (E-mail)'" Subject: Re: [ldapext] RE:draft-behera-ldap-password-policy-07.txt References: <00d501c400ea$5f799f90$1801a8c0@CELLO> In-Reply-To: <00d501c400ea$5f799f90$1801a8c0@CELLO> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Yes it should and it's been corrected now. Thanks for pointing it out. Ludovic. Howard Chu wrote: >Section 7 page 27, shouldn't this be: > > In the event that the passwordPolicyRequest > control was not sent, no passwordPolicyResponse control is returned. > ^^^^^^^^ > > -- Howard Chu > Chief Architect, Symas Corp. Director, Highland Sun > http://www.symas.com http://highlandsun.com/hyc > Symas: Premier OpenSource Development and Support > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext > > -- Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Mar 3 02:14:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20777 for ; Wed, 3 Mar 2004 02:14:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQZt-0003Ng-Nd; Wed, 03 Mar 2004 02:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQZE-00034K-Uc for ldapext@optimus.ietf.org; Wed, 03 Mar 2004 02:13:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20633 for ; Wed, 3 Mar 2004 02:13:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQZB-0006cI-00 for ldapext@ietf.org; Wed, 03 Mar 2004 02:13:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQYg-0006U1-00 for ldapext@ietf.org; Wed, 03 Mar 2004 02:12:47 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AyQXn-0006Kq-00 for ldapext@ietf.org; Wed, 03 Mar 2004 02:11:51 -0500 Received: from odin.France.Sun.COM ([129.157.174.8]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i237Bni5017267; Wed, 3 Mar 2004 00:11:50 -0700 (MST) Received: from Sun.COM (vpn-129-150-116-10.UK.Sun.COM [129.150.116.10]) by odin.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id i237BlP07751; Wed, 3 Mar 2004 08:11:48 +0100 (MET) Message-ID: <404584FE.1030003@Sun.COM> Date: Wed, 03 Mar 2004 08:10:54 +0100 From: Ludovic Poitou Organization: SUN Microsystems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Howard Chu CC: ldapext@ietf.org Subject: Re: [ldapext] RE:draft-behera-ldap-password-policy-07.txt References: <00d801c400eb$89e75410$1801a8c0@CELLO> In-Reply-To: <00d801c400eb$89e75410$1801a8c0@CELLO> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Howard Chu wrote: >Section 6 page 17 (top) again: > In the event that the passwordPolicyRequest control > was not sent, no passwordPolicyResponse control is returned. > ^^^^^^^^ > > > Thanks again. >>-----Original Message----- >>From: Howard Chu [mailto:hyc@highlandsun.com] >> >> > > > >>From a purist's security perspective, I'd agree that >>invalidCredentials is the correct response. One of the maxims >>in security is to provide the minimal amount of information >>to an attacker. Thus, one is advised to avoid giving >>responses that differentiate between "account does not exist" >>/ "password is incorrect" / "account locked due to too many >>failed attempts" ... Following this argument, I wouldn't even >>provide any special information in the passwordPolicyResponse control. >> >> > >So I would change 6.1.1 > > If the account is locked, the server MUST send a bindResponse to > the client with the resultCode: invalidCredentials (49). The server > MAY set the error: accountLocked (1) in the passwordPolicyResponse > in the controls field of the bindResponse message. > >I.e., I would like to leave it up to the admin to decide whether this error >code should be returned or not. > > > This is a reasonable requirement that I'm inclined to include in the document. Ludovic. > -- Howard Chu > Chief Architect, Symas Corp. Director, Highland Sun > http://www.symas.com http://highlandsun.com/hyc > Symas: Premier OpenSource Development and Support > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext > > -- Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Mar 3 10:11:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02838 for ; Wed, 3 Mar 2004 10:11:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyY1W-000242-9l; Wed, 03 Mar 2004 10:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyY18-0001xy-4J for ldapext@optimus.ietf.org; Wed, 03 Mar 2004 10:10:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02741 for ; Wed, 3 Mar 2004 10:10:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyY16-0005me-00 for ldapext@ietf.org; Wed, 03 Mar 2004 10:10:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyY0F-0005d7-00 for ldapext@ietf.org; Wed, 03 Mar 2004 10:09:44 -0500 Received: from prv-mail20.provo.novell.com ([137.65.81.122]) by ietf-mx with esmtp (Exim 4.12) id 1AyXzf-0005RE-00 for ldapext@ietf.org; Wed, 03 Mar 2004 10:09:08 -0500 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 03 Mar 2004 08:08:35 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Wed, 03 Mar 2004 08:08:17 -0700 From: "Jim Sermersheim" To: Subject: Fwd: RE: [ldapext] RE:draft-behera-ldap-password-policy-07.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part684960F1.0__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part684960F1.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit The original intent was that it would be returned (when requested) only when information needed to be conveyed. We can clarify if needed, but I'm interested if you see a reason to prefer one of your other possibilities. Thanks, Jim >>> andrews@adacel.com.au 3/2/04 7:07:02 PM >>> >-----Original Message----- >From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org]On >Behalf Of >Howard Chu >Sent: Wednesday, 3 March 2004 4:07 >To: ldapext@ietf.org >Subject: Re: [ldapext] RE:draft-behera-ldap-password-policy-07.txt >... Following >this argument, I wouldn't even provide any special information in the >passwordPolicyResponse control. > Bringing us back to the question: When is the password policy control returned? * Always, or * Every time important information needs to be conveyed, or * Only for specific operations as stated in section 5.2 * Only for specific operations as stated in section 5.2 and important information must be conveyed, or * When the operation has succeeded/failed due to the password policy regardless of the operation and whether we have important information to convey. (The above list is based on the fact that the client has provided a request control) Cheers, Andrew Sciberras. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__Part684960F1.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The original intent was that it would be returned (when requested) = only when information needed to be conveyed.
 
We can clarify if needed, but I'm interested if you see a reason to = prefer one of your other possibilities.
 
Thanks,
 
Jim

>>> andrews@adacel.com.au 3/2/04 7:07:02 PM = >>>
>-----Original Message-----
>From: ldapext-admin@ietf.org = [mailto:ldapext-adm= in@ietf.org]On
>Behalf Of
>Howard Chu
>Sent: = Wednesday, 3 March 2004 4:07
>To: ldapext@ietf.org
>Subject: Re: [ldapext] RE:draft-behera= -ldap-password-policy-07.txt

<snip>

>... Following>this argument, I wouldn't even provide any special information in = the
>passwordPolicyResponse control.
>

Bringing us back = to the question: When is the password policy control
returned?
* = Always, or
* Every time important information needs to be conveyed, = or
* Only for specific operations as stated in section 5.2
* Only = for specific operations as stated in section 5.2 and important
informati= on must be conveyed, or
* When the operation has succeeded/failed due = to the password policy
regardless of the operation and whether we have = important information to
convey.

(The above list is based on the = fact that the client has provided a request
control)

Cheers,
A= ndrew Sciberras.


_______________________________________________=
Ldapext mailing list
Ldapext@= ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext
--=__Part684960F1.0__=-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Mar 3 20:53:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14471 for ; Wed, 3 Mar 2004 20:53:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayi2n-0001Yj-8y; Wed, 03 Mar 2004 20:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayi21-0001K1-8y for ldapext@optimus.ietf.org; Wed, 03 Mar 2004 20:52:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14349 for ; Wed, 3 Mar 2004 20:52:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayi1y-00030z-00 for ldapext@ietf.org; Wed, 03 Mar 2004 20:52:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayi11-0002pH-00 for ldapext@ietf.org; Wed, 03 Mar 2004 20:51:12 -0500 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayi0K-0002cS-00 for ldapext@ietf.org; Wed, 03 Mar 2004 20:50:28 -0500 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.5.9) id ; Thu, 04 Mar 2004 12:40:49 +1100 Received: (qmail 12123 invoked from network); 4 Mar 2004 01:49:55 -0000 Received: from unknown (HELO shylock) (10.32.24.166) by nexus.adacel.com with SMTP; 4 Mar 2004 01:49:55 -0000 Reply-To: From: "Andrew Sciberras" To: "'Jim Sermersheim'" Cc: "Ldapext \(E-mail\)" Subject: RE: RE: [ldapext] RE:draft-behera-ldap-password-policy-07.txt Date: Thu, 4 Mar 2004 12:49:54 +1100 Message-ID: <00b501c4018a$fe558a70$a618200a@mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B6_01C401E7.31C60270" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_00B6_01C401E7.31C60270 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit G'Day Since the next revision of the draft will indicate the servers should include the control in the 'SupportedControls' attribute, I can respect the fact the control should only be returned (when requested) to convey important information. That being said, the draft is counter to this by returning controls that only contain an empty sequence (E.g. Bind and Compare). Some may also interpret section to 5.2 to suggest that the control is always returned (when requested) for specific operations. Cheers, Andrew Sciberras ------=_NextPart_000_00B6_01C401E7.31C60270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
G'Day
 
Since the=20 next revision of the draft will indicate the servers should include the = control=20 in the 'SupportedControls' attribute, I can respect the fact the control = should=20 only be returned (when requested) to convey important information.=20
 
That being=20 said, the draft is counter to this by returning controls that only = contain=20 an empty sequence (E.g. Bind and Compare).
Some may also interpret section to = 5.2 to=20 suggest that the control is always returned (when requested) for = specific=20 operations.
 
Cheers,
Andrew=20 Sciberras          &nbs= p;  
------=_NextPart_000_00B6_01C401E7.31C60270-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Mar 4 03:04:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26521 for ; Thu, 4 Mar 2004 03:04:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aynps-0007HY-Cx; Thu, 04 Mar 2004 03:04:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynpI-0006yr-G5 for ldapext@optimus.ietf.org; Thu, 04 Mar 2004 03:03:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26390 for ; Thu, 4 Mar 2004 03:03:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AynpE-0001nH-00 for ldapext@ietf.org; Thu, 04 Mar 2004 03:03:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayno9-0001SK-00 for ldapext@ietf.org; Thu, 04 Mar 2004 03:02:18 -0500 Received: from [62.80.60.98] (helo=nb2.stroeder.com) by ietf-mx with esmtp (Exim 4.12) id 1AynmS-0000ji-00 for ldapext@ietf.org; Thu, 04 Mar 2004 03:00:33 -0500 Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 77FAA7F473; Thu, 4 Mar 2004 08:12:26 +0100 (CET) Message-ID: <4046D6DA.3090703@stroeder.com> Date: Thu, 04 Mar 2004 08:12:26 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Howard Chu Cc: ldapext@ietf.org Subject: Re: [ldapext] RE:draft-behera-ldap-password-policy-07.txt References: <00a901c40078$d07b8d10$1801a8c0@CELLO> In-Reply-To: <00a901c40078$d07b8d10$1801a8c0@CELLO> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Howard Chu wrote: > > From a purist's security perspective, I'd agree that invalidCredentials is > the correct response. One of the maxims in security is to provide the minimal > amount of information to an attacker. Thus, one is advised to avoid giving > responses that differentiate between "account does not exist" / "password is > incorrect" / "account locked due to too many failed attempts" ... Following > this argument, I wouldn't even provide any special information in the > passwordPolicyResponse control. This would make a password policy a 1st-level support nightmare. And it's security by obscurity which does not really work against serious attacks anyway. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Mar 4 12:41:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03789 for ; Thu, 4 Mar 2004 12:41:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AywqD-0003J1-UT; Thu, 04 Mar 2004 12:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aywpt-0003Ft-E9 for ldapext@optimus.ietf.org; Thu, 04 Mar 2004 12:40:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03775 for ; Thu, 4 Mar 2004 12:40:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aywpr-0003Xc-00 for ldapext@ietf.org; Thu, 04 Mar 2004 12:40:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aywoy-0003O3-00 for ldapext@ietf.org; Thu, 04 Mar 2004 12:39:44 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx with esmtp (Exim 4.12) id 1AywoD-0003EK-00 for ldapext@ietf.org; Thu, 04 Mar 2004 12:38:58 -0500 Received: from CELLO (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.12.9/8.12.9) with SMTP id i24HcibL000909 for ; Thu, 4 Mar 2004 11:38:45 -0600 From: "Howard Chu" To: Subject: Re: [ldapext] RE:draft-behera-ldap-password-policy-07.txt Date: Thu, 4 Mar 2004 09:38:34 -0800 Message-ID: <004401c4020f$8aa6aac0$8601a8c0@CELLO> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040304170007.30226.25589.Mailman@www1.ietf.org> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Date: Thu, 04 Mar 2004 08:12:26 +0100 > From: =?ISO-8859-1?Q?Michael_Str=F6der?= > Howard Chu wrote: > > > > From a purist's security perspective, I'd agree that > invalidCredentials is > > the correct response. One of the maxims in security is to > provide the minimal > > amount of information to an attacker. Thus, one is advised > to avoid giving > > responses that differentiate between "account does not > exist" / "password is > > incorrect" / "account locked due to too many failed > attempts" ... Following > > this argument, I wouldn't even provide any special > information in the > > passwordPolicyResponse control. > > This would make a password policy a 1st-level support > nightmare. Making it optional as I suggested is harmless; your site can enable this result if you feel the need. Making it mandatory is harmful; I have worked on a number of US government projects where computer systems are expressly forbidden from revealing this kind of status. I think your objection is a moot point if the feature is optional. > And it's > security by obscurity which does not really work against > serious attacks anyway. No, this is not the same as "security by obscurity." A better illustration would be to compare it to a silent alarm system in the real world. When the intruder doesn't know that his intrusion has been detected, he remains on the scene, giving time for authorities to arrive and catch him in the act. An attacker that doesn't know the account has been locked is likely to continue probing it with Bind attempts. If they know for certain it has been disabled, they will move on. There is real value in not letting the attacker know that the attack has been detected, because it gives a greater opportunity to trace the attack. Not all LDAP servers need to be user-friendly; the protocol should allow for other possibilities. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Mar 4 13:04:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04703 for ; Thu, 4 Mar 2004 13:04:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyxCT-0006UE-6v; Thu, 04 Mar 2004 13:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyxC8-0006TV-Aq for ldapext@optimus.ietf.org; Thu, 04 Mar 2004 13:03:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04657 for ; Thu, 4 Mar 2004 13:03:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyxC6-0000DB-00 for ldapext@ietf.org; Thu, 04 Mar 2004 13:03:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyxB7-00001U-00 for ldapext@ietf.org; Thu, 04 Mar 2004 13:02:38 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx with esmtp (Exim 4.12) id 1AyxA6-0007VJ-00 for ldapext@ietf.org; Thu, 04 Mar 2004 13:01:34 -0500 Received: from CELLO (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.12.9/8.12.9) with SMTP id i24I1RJT001348 for ; Thu, 4 Mar 2004 12:01:27 -0600 From: "Howard Chu" To: Subject: Re: [ldapext] RE:draft-behera-ldap-password-policy-07.txt Date: Thu, 4 Mar 2004 10:01:06 -0800 Message-ID: <004501c40212$b6b2bb10$8601a8c0@CELLO> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040304170007.30226.25589.Mailman@www1.ietf.org> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In general I see the LDAP unwillingToPerform result code used to mean *unable* to perform - i.e., the requested operation is unimplemented and the target server can *never* satisfy a request. Of course the LDAP spec doesn't define it this way, but that appears to me to be the most common usage. (Am I missing the point somewhere?) I am uncomfortable with its use in this draft for errors which are unrelated to the actual capabilities implemented by the server. E.g., 6.2.3 should just return insufficientAccessRights. Is my concern unnecessary? -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Mar 4 20:30:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26197 for ; Thu, 4 Mar 2004 20:30:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4A7-0003KZ-2z; Thu, 04 Mar 2004 20:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az49B-0003H1-KU for ldapext@optimus.ietf.org; Thu, 04 Mar 2004 20:29:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26103 for ; Thu, 4 Mar 2004 20:29:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az499-0005lL-00 for ldapext@ietf.org; Thu, 04 Mar 2004 20:29:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az48B-0005aG-00 for ldapext@ietf.org; Thu, 04 Mar 2004 20:28:03 -0500 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1Az47p-0005Q5-00 for ldapext@ietf.org; Thu, 04 Mar 2004 20:27:41 -0500 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i251RVMs003301; Fri, 5 Mar 2004 01:27:33 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040305102121.04f9b630@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 05 Mar 2004 10:27:31 +0900 To: "Howard Chu" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] RE:draft-behera-ldap-password-policy-07.txt Cc: In-Reply-To: <004501c40212$b6b2bb10$8601a8c0@CELLO> References: <20040304170007.30226.25589.Mailman@www1.ietf.org> <004501c40212$b6b2bb10$8601a8c0@CELLO> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , I haven't look at the particular usage, but I think that specifically calling for the return of unwillingToPerform is not a good idea. It, like a number of general result codes, should be left to the implementor to decide between (other, busy, ...). Or, to put it another way, specifications should not attach narrow semantics to a general purpose result code. If something needs to be called out specifically, it likely better to use a new code. Kurt At 03:01 AM 3/5/2004, Howard Chu wrote: >In general I see the LDAP unwillingToPerform result code used to mean >*unable* to perform - i.e., the requested operation is unimplemented and the >target server can *never* satisfy a request. Of course the LDAP spec doesn't >define it this way, but that appears to me to be the most common usage. (Am I >missing the point somewhere?) > >I am uncomfortable with its use in this draft for errors which are unrelated >to the actual capabilities implemented by the server. E.g., 6.2.3 should just >return insufficientAccessRights. Is my concern unnecessary? > > -- Howard Chu > Chief Architect, Symas Corp. Director, Highland Sun > http://www.symas.com http://highlandsun.com/hyc > Symas: Premier OpenSource Development and Support > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Sat Mar 6 20:41:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14689 for ; Sat, 6 Mar 2004 20:41:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AznHp-0001Wy-Vl; Sat, 06 Mar 2004 20:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AznGw-0001VX-RG for ldapext@optimus.ietf.org; Sat, 06 Mar 2004 20:40:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14651 for ; Sat, 6 Mar 2004 20:40:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AznGu-0000ss-00 for ldapext@ietf.org; Sat, 06 Mar 2004 20:40:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AznFw-0000lG-00 for ldapext@ietf.org; Sat, 06 Mar 2004 20:39:05 -0500 Received: from [203.17.154.98] (helo=mail.velocitynet.com.au) by ietf-mx with esmtp (Exim 4.12) id 1AznFY-0000db-00 for ldapext@ietf.org; Sat, 06 Mar 2004 20:38:40 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.velocitynet.com.au (Postfix) with ESMTP id A977897C20A; Sun, 7 Mar 2004 12:37:47 +1100 (EST) Received: from mail.velocitynet.com.au ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16248-26; Sun, 7 Mar 2004 12:37:15 +1100 (EST) Received: from yowiee.bartlett.house (177.196.221.203.velocitynet.com.au [203.221.196.177]) by mail.velocitynet.com.au (Postfix) with ESMTP id 7653E97C27B; Sun, 7 Mar 2004 12:37:15 +1100 (EST) Received: from [192.168.1.12] (abartlet@[192.168.1.12]) by yowiee.bartlett.house (8.12.10/8.12.8) with ESMTP id i271c6Db022692; Sun, 7 Mar 2004 12:38:06 +1100 From: Andrew Bartlett To: ldapext@ietf.org Cc: Multiple recipients of list SAMBA-TECHNICAL Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-v/9apqRR0MKPhnrQGTgQ" Message-Id: <1078623486.1722.49.camel@piglett.bartlett.house> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Sun, 07 Mar 2004 12:38:06 +1100 X-Virus-Scanned: by amavisd-new at velocitynet.com.au X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [ldapext] Samba and the password policy draft Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , --=-v/9apqRR0MKPhnrQGTgQ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I have recently been made aware of the existence of=20 draft-behera-ldap-password-policy-07.txt and I would like to work with the ldapext group to make Samba suitable for us with it, and the draft suitable for use with Samba (as well as a number of other tools in this class, being Cyrus-SASL and Heimdal's hdb-ldap in particular). These tools all have one thing in common, that is that they do not generally ship cleartext passwords to LDAP when checking passwords.=20 Instead, they use administrative rights to read the user's password and perform challenge-response on them. =20 Similarly, these tools often do not have the original plaintext password for password changes, only the new plaintext. Again, this means that these operations are performed as some administrative user. However, I can see great value in ensuring that Samba complies with the password policies in force on the rest of the directory, and more particularly, to allow Samba password policies (in some way derived from what MS does, as we match our NT4 semantics) to be set in the directory, using both NT and native LDAP tools. What I am looking for is some additional control or operation that may be used by Samba/Heimdal/etc to say 'a user just logged in, with the right password', and 'a user just tried to log in with a wrong password'. =20 Likewise, some additional control to say 'this password change on behalf of a user', would fix my second concern. =20 I realise that these could be considered to be 'not LDAP's problem' (as it regards password comparisons outside the directory), but in the interests of seamless directory integration, I hope that some accommodation can be made, particularly in the interests of cross-protocol, cross-application consistency. (Indeed Samba and some other tools may read the user's plaintext password out of the userPassword attribute. It would be a pity to defeat the max bad password checks while attempting to make an administrator's live *easier*...) Finally, I apologise if I have messed up some of the finer details of LDAP here. While I have spent a lot of time (along with many others) working of pdb_ldap in Samba, I am far from an LDAP guru... Is this something the working group is willing to consider? Andrew Bartlett --=20 Andrew Bartlett abartlet@pcug.org.au Manager, Authentication Subsystems, Samba Team abartlet@samba.org Student Network Administrator, Hawker College abartlet@hawkerc.net http://samba.org http://build.samba.org http://hawkerc.net --=-v/9apqRR0MKPhnrQGTgQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQBASnz9w6AkmCjZ77cRArW2AJ9vZ8dycOc+bdbbEkD3S0eYyvmfpACfeciI YPLtiD++iaJpmPkhA9Eg/30= =Ntro -----END PGP SIGNATURE----- --=-v/9apqRR0MKPhnrQGTgQ-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Sat Mar 6 21:21:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15815 for ; Sat, 6 Mar 2004 21:21:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AznuX-0003vJ-Hn; Sat, 06 Mar 2004 21:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Azntl-0003tF-59 for ldapext@optimus.ietf.org; Sat, 06 Mar 2004 21:20:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15782 for ; Sat, 6 Mar 2004 21:20:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aznti-0006eQ-00 for ldapext@ietf.org; Sat, 06 Mar 2004 21:20:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aznsn-0006W5-00 for ldapext@ietf.org; Sat, 06 Mar 2004 21:19:13 -0500 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1Aznrl-0006Mf-00 for ldapext@ietf.org; Sat, 06 Mar 2004 21:18:09 -0500 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i272I4Ms035525; Sun, 7 Mar 2004 02:18:04 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040306181135.04ca1e18@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 06 Mar 2004 18:18:04 -0800 To: Andrew Bartlett From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Samba and the password policy draft Cc: ldapext@ietf.org, Multiple recipients of list SAMBA-TECHNICAL In-Reply-To: <1078623486.1722.49.camel@piglett.bartlett.house> References: <1078623486.1722.49.camel@piglett.bartlett.house> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 05:38 PM 3/6/2004, Andrew Bartlett wrote: >Is this something the working group is willing to consider? For clarity, note that the LDAPEXT working group is concluded. The LDAPEXT list is just a convenient place to discuss LDAP extensions, but all the works in progress discussed here are independent submissions (whether Standard Track (and hence to the IETF) or Informational/Experimental (and hence to the RFC Editor)). So, the more appropriate question would be s/working group/authors/. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Mar 8 17:43:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07976 for ; Mon, 8 Mar 2004 17:43:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TSf-000267-US; Mon, 08 Mar 2004 17:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TSZ-00025U-P8 for ldapext@optimus.ietf.org; Mon, 08 Mar 2004 17:42:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07945 for ; Mon, 8 Mar 2004 17:42:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TSX-0002kD-00 for ldapext@ietf.org; Mon, 08 Mar 2004 17:42:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TRa-0002br-00 for ldapext@ietf.org; Mon, 08 Mar 2004 17:41:55 -0500 Received: from prv-mail20.provo.novell.com ([137.65.81.122]) by ietf-mx with esmtp (Exim 4.12) id 1B0TQp-0002M9-00 for ldapext@ietf.org; Mon, 08 Mar 2004 17:41:07 -0500 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 08 Mar 2004 15:40:36 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 08 Mar 2004 15:40:16 -0700 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartD2F3D340.0__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Subject: [ldapext] Support for NSSRs Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartD2F3D340.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit All, As we move closer to beginning to define the LDAP distributed directory model, I propose that we seriously consider dropping support for non-specific subordinate references (NSSR)s. There are problems in implementing this type of reference, and as far as I know, there aren't good use cases for it (see Section 9.2 of the "WEIRD AND WONDERFUL" section at http://www.isi.salford.ac.uk/staff/dwc/Version.Web/Chapter.9/Chapter9c.htm. One particularly sticky problem is this: Say an NSSR holds five referral URIs. Two point to DSAs that hold different naming contexts, and three point to DSAs which replicate a single naming context. There is nothing that sets URIs representing copies of naming contexts apart from those representing different naming contexts. Thus, a protocol peer that recieves a searchResultReference due to this NSSR will erroneously progress the search on two DSAs that hold the same data. There are other problems when adding subordinate objects to an NSSR. If you know of reasons that NSSRs should be supported, and how these types of problems can be overcome, please reply. Thanks. Jim --=__PartD2F3D340.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,
 
As we move closer to beginning to define the LDAP distributed = directory model, I propose that we seriously consider dropping support for = non-specific subordinate references (NSSR)s.
 
There are problems in implementing this type of reference, and as far = as I know, there aren't good use cases for it (see Section 9.2 of the = "WEIRD AND WONDERFUL" section at http://www.isi.salford.ac.uk/s= taff/dwc/Version.Web/Chapter.9/Chapter9c.htm.
 
One particularly sticky problem is this:
 
Say an NSSR holds five referral URIs. Two point to DSAs that = hold different naming contexts, and three point to DSAs which = replicate a single naming context. There is nothing that sets URIs = representing copies of naming contexts apart from those representing = different naming contexts. Thus, a protocol peer that recieves a searchResu= ltReference due to this NSSR will erroneously progress the search on two = DSAs that hold the same data.
 
There are other problems when adding subordinate objects to an = NSSR.
 
If you know of reasons that NSSRs should be supported, and how these = types of problems can be overcome, please reply.
 
Thanks.
 
Jim
--=__PartD2F3D340.0__=-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Mar 8 19:10:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12579 for ; Mon, 8 Mar 2004 19:10:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Uot-0002OH-Ic; Mon, 08 Mar 2004 19:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Uoq-0002NW-FV for ldapext@optimus.ietf.org; Mon, 08 Mar 2004 19:10:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12551 for ; Mon, 8 Mar 2004 19:09:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Uon-0001P3-00 for ldapext@ietf.org; Mon, 08 Mar 2004 19:09:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Unm-0001FQ-00 for ldapext@ietf.org; Mon, 08 Mar 2004 19:08:55 -0500 Received: from prv-mail20.provo.novell.com ([137.65.81.122]) by ietf-mx with esmtp (Exim 4.12) id 1B0Ump-0000yq-00 for ldapext@ietf.org; Mon, 08 Mar 2004 19:07:55 -0500 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 08 Mar 2004 17:07:24 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 08 Mar 2004 17:07:06 -0700 From: "Jim Sermersheim" To: , "Vince Brimhall" , Cc: Subject: Re: [ldapext] Samba and the password policy draft Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartD5F4D5BA.0__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartD5F4D5BA.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Andrew, (speaking on behalf of the other LDAP password policy I-D authors) This kind of integration is something we do want to consider. Before we look at adding additional operations though, can we talk about the reasons that prevent these applications from using existing LDAP operations? Our guess is that it has to do with the fact that Samba fetches either an NT or LM hashed password from the directory, and uses that to perform the comparison. The NT/LM hash doesn't work with LDAP simple bind because LDAP simple bind requires a clear text password. I'm wondering if there's something preventing the use of an NT/LM SASL mechanism to perform an LDAP SASL bind. Novell is beginning to look at doing just that and will contribute to the code if it's seen as beneficial. If this were available, the password policy could still be enforced by the LDAP server Then for password modifications, there is RFC 3602. Do you think this is sufficient to update these kinds of passwords? Note that the new password is optional. Also note that we *could* update the policy draft such that the pwdSafeModify requires either the old password, or a trusted identity to make the change. I know that for both of these to work, the server will need to support the SASL mechanism, and allow itself to be configured to populate the correct attributes when the password modify operation is used. Let me know your thoughts on pushing in this direction. Jim >>> Andrew Bartlett 3/6/04 6:38:06 PM >>> I have recently been made aware of the existence of draft-behera-ldap-password-policy-07.txt and I would like to work with the ldapext group to make Samba suitable for us with it, and the draft suitable for use with Samba (as well as a number of other tools in this class, being Cyrus-SASL and Heimdal's hdb-ldap in particular). These tools all have one thing in common, that is that they do not generally ship cleartext passwords to LDAP when checking passwords. Instead, they use administrative rights to read the user's password and perform challenge-response on them. Similarly, these tools often do not have the original plaintext password for password changes, only the new plaintext. Again, this means that these operations are performed as some administrative user. However, I can see great value in ensuring that Samba complies with the password policies in force on the rest of the directory, and more particularly, to allow Samba password policies (in some way derived from what MS does, as we match our NT4 semantics) to be set in the directory, using both NT and native LDAP tools. What I am looking for is some additional control or operation that may be used by Samba/Heimdal/etc to say 'a user just logged in, with the right password', and 'a user just tried to log in with a wrong password'. Likewise, some additional control to say 'this password change on behalf of a user', would fix my second concern. I realise that these could be considered to be 'not LDAP's problem' (as it regards password comparisons outside the directory), but in the interests of seamless directory integration, I hope that some accommodation can be made, particularly in the interests of cross-protocol, cross-application consistency. (Indeed Samba and some other tools may read the user's plaintext password out of the userPassword attribute. It would be a pity to defeat the max bad password checks while attempting to make an administrator's live *easier*...) Finally, I apologise if I have messed up some of the finer details of LDAP here. While I have spent a lot of time (along with many others) working of pdb_ldap in Samba, I am far from an LDAP guru... Is this something the working group is willing to consider? Andrew Bartlett -- Andrew Bartlett abartlet@pcug.org.au Manager, Authentication Subsystems, Samba Team abartlet@samba.org Student Network Administrator, Hawker College abartlet@hawkerc.net http://samba.org http://build.samba.org http://hawkerc.net --=__PartD5F4D5BA.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Andrew,
 
(speaking on behalf of the other LDAP password policy I-D authors) = This kind of integration is something we do want to consider.
 
Before we look at adding additional operations though, can we talk = about the reasons that prevent these applications from using existing LDAP = operations? Our guess is that it has to do with the fact that Samba = fetches either an NT or LM hashed password from the directory, and uses = that to perform the comparison. The NT/LM hash doesn't work with LDAP = simple bind because LDAP simple bind requires a clear text password.
 
I'm wondering if there's something preventing the use of an NT/LM = SASL mechanism to perform an LDAP SASL bind. Novell is beginning to look = at doing just that and will contribute to the code if it's seen as = beneficial. If this were available, the password policy could still be = enforced by the LDAP server
 
Then for password modifications, there is RFC 3602. Do you think this = is sufficient to update these kinds of passwords?
Note that the new password is optional.
Also note that we *could* update the policy draft such that the = pwdSafeModify requires either the old password, or a trusted identity to = make the change.
 
I know that for both of these to work, the server will need to = support the SASL mechanism, and allow itself to be configured to populate = the correct attributes when the password modify operation is used.
 
Let me know your thoughts on pushing in this direction.
 
Jim

>>> Andrew Bartlett <abartlet@samba.org> 3/6/04 = 6:38:06 PM >>>
I have recently been made aware of the = existence of

draft-behera-ldap-password-policy-07.txt

and I = would like to work with the ldapext group to make Samba suitable
for us = with it, and the draft suitable for use with Samba (as well as a
number = of other tools in this class, being Cyrus-SASL and Heimdal's
hdb-ldap = in particular).

These tools all have one thing in common, that is = that they do not
generally ship cleartext passwords to LDAP when = checking passwords.
Instead, they use administrative rights to read = the user's password and
perform challenge-response on them.

Simi= larly, these tools often do not have the original plaintext password
for= password changes, only the new plaintext. Again, this means that
these = operations are performed as some administrative user.

However, I = can see great value in ensuring that Samba complies with the
password = policies in force on the rest of the directory, and more
particularly, = to allow Samba password policies (in some way derived from
what MS = does, as we match our NT4 semantics) to be set in the directory,
using = both NT and native LDAP tools.

What I am looking for is some = additional control or operation that may
be used by Samba/Heimdal/etc = to say 'a user just logged in, with the
right password', and 'a user = just tried to log in with a wrong
password'.

Likewise, some = additional control to say 'this password change on behalf
of a user', = would fix my second concern.

I realise that these could be = considered to be 'not LDAP's problem' (as
it regards password comparison= s outside the directory), but in the
interests of seamless directory = integration, I hope that some
accommodation can be made, particularly = in the interests of
cross-protocol, cross-application consistency.
(Indeed Samba and some other tools may read the user's plaintext
passw= ord out of the userPassword attribute. It would be a pity to
defeat the = max bad password checks while attempting to make an
administrator's = live *easier*...)

Finally, I apologise if I have messed up some of = the finer details of
LDAP here. While I have spent a lot of time (along = with many others)
working of pdb_ldap in Samba, I am far from an LDAP = guru...

Is this something the working group is willing to consider?<= BR>
Andrew Bartlett
--
Andrew Bartlett abartlet@pcug.org.au
Manager, Authentication = Subsystems, Samba Team abartlet@sa= mba.org
Student Network Administrator, Hawker College abartlet@hawkerc.net =
http://samba.org http://build.samba.org http://hawkerc.net
--=__PartD5F4D5BA.0__=-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Mar 8 19:47:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14047 for ; Mon, 8 Mar 2004 19:47:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0VOe-0004Wm-TW; Mon, 08 Mar 2004 19:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0VNl-0004VT-Oy for ldapext@optimus.ietf.org; Mon, 08 Mar 2004 19:46:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14012 for ; Mon, 8 Mar 2004 19:46:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0VNk-000722-00 for ldapext@ietf.org; Mon, 08 Mar 2004 19:46:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0VMs-0006sw-00 for ldapext@ietf.org; Mon, 08 Mar 2004 19:45:11 -0500 Received: from [203.17.154.98] (helo=mail.velocitynet.com.au) by ietf-mx with esmtp (Exim 4.12) id 1B0VM2-0006jC-00 for ldapext@ietf.org; Mon, 08 Mar 2004 19:44:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.velocitynet.com.au (Postfix) with ESMTP id 3519197C216; Tue, 9 Mar 2004 11:43:15 +1100 (EST) Received: from mail.velocitynet.com.au ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01893-39; Tue, 9 Mar 2004 11:42:43 +1100 (EST) Received: from yowiee.bartlett.house (177.196.221.203.velocitynet.com.au [203.221.196.177]) by mail.velocitynet.com.au (Postfix) with ESMTP id A67F197C297; Tue, 9 Mar 2004 11:42:42 +1100 (EST) Received: from [192.168.1.12] (abartlet@[192.168.1.12]) by yowiee.bartlett.house (8.12.10/8.12.8) with ESMTP id i290hdDb001996; Tue, 9 Mar 2004 11:43:39 +1100 Subject: Re: [ldapext] Samba and the password policy draft From: Andrew Bartlett To: Jim Sermersheim Cc: ldapext@ietf.org, Vince Brimhall , abartlet@samba.org, Multiple recipients of list SAMBA-TECHNICAL In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-nGwNqwVyHVyMcd74LHCx" Message-Id: <1078793018.7483.11.camel@piglett.bartlett.house> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Tue, 09 Mar 2004 11:43:38 +1100 X-Virus-Scanned: by amavisd-new at velocitynet.com.au X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , --=-nGwNqwVyHVyMcd74LHCx Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-03-09 at 11:07, Jim Sermersheim wrote: > Andrew, > =20 > (speaking on behalf of the other LDAP password policy I-D authors) > This kind of integration is something we do want to consider. > =20 > Before we look at adding additional operations though, can we talk > about the reasons that prevent these applications from using existing > LDAP operations? Our guess is that it has to do with the fact that > Samba fetches either an NT or LM hashed password from the directory, > and uses that to perform the comparison. The NT/LM hash doesn't work > with LDAP simple bind because LDAP simple bind requires a clear text > password. Correct. > I'm wondering if there's something preventing the use of an NT/LM SASL > mechanism to perform an LDAP SASL bind. Novell is beginning to look at > doing just that and will contribute to the code if it's seen as > beneficial. If this were available, the password policy could still be > enforced by the LDAP server NO. This is not suitable for a SASL mechanism, as this is a challenge-response that is done by Samba, or a Samba client (being an NT domain member server, for example). We simply get the result of the challenge-response, we can't specify the inputs. =20 Even if you hacked a solution to that, consider Heimdal and Cyrus-SASL (backed against an LDAP password store)... =20 > Then for password modifications, there is RFC 3602.=20 RFC 3602 - The AES-CBC Cipher Algorithm and Its Use with IPsec?? Ahh, you mean 3062 :-). Samba already supports this, and indeed it is my proposal that we use this to perform the password set, when we have the plaintext password. We currently still set the NT and LM passwords manually, but it is my hope that in the future, the LDAP server will know how to populate the required attributes itself. A patch implementing this for OpenLDAP is in the works. Indeed it was my proposal to use exactly this (using our existing pdb_ldap and 'ldap password sync =3D only' in the smb.conf) when Novell expressed an interest in providing an eDirectory passdb backend for Samba. > Do you think this is sufficient to update these kinds of passwords?=20 > Note that the new password is optional. > Also note that we *could* update the policy draft such that the > pwdSafeModify requires either the old password, or a trusted identity > to make the change.=20 This would be good. The only thing I need in addition is for the server to support still considering this to be a 'user modify', so as to check the 'quality' against user, not administrator rules (I presume the admin is exempt from the rules). > I know that for both of these to work, the server will need to support > the SASL mechanism, and allow itself to be configured to populate the > correct attributes when the password modify operation is used. > =20 > Let me know your thoughts on pushing in this direction. The SASL stuff is a non-starter, but the password modify stuff is exactly what I am thinking. Andrew Bartlett --=20 Andrew Bartlett abartlet@pcug.org.au Manager, Authentication Subsystems, Samba Team abartlet@samba.org Student Network Administrator, Hawker College abartlet@hawkerc.net http://samba.org http://build.samba.org http://hawkerc.net --=-nGwNqwVyHVyMcd74LHCx Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQBATRM5w6AkmCjZ77cRAgs0AJ9IXlMDGlLooPGIMR+1NTOvCrVm5QCeJpf9 qJAnI+bZc6DHaoQOIgQUtL8= =ZvDR -----END PGP SIGNATURE----- --=-nGwNqwVyHVyMcd74LHCx-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Mar 8 21:55:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17816 for ; Mon, 8 Mar 2004 21:55:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0XOY-0003Dy-S0; Mon, 08 Mar 2004 21:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0XNj-00037n-OP for ldapext@optimus.ietf.org; Mon, 08 Mar 2004 21:54:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17808 for ; Mon, 8 Mar 2004 21:54:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0XNg-0003ku-00 for ldapext@ietf.org; Mon, 08 Mar 2004 21:54:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0XMj-0003cI-00 for ldapext@ietf.org; Mon, 08 Mar 2004 21:53:10 -0500 Received: from au.padl.com ([203.13.32.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0XM8-0003Jz-00 for ldapext@ietf.org; Mon, 08 Mar 2004 21:52:32 -0500 Received: (from lukeh@localhost) by au.padl.com (8.9.3/8.9.3) id NAA01927; Tue, 9 Mar 2004 13:51:46 +1100 (EST) From: Luke Howard Message-Id: <200403090251.NAA01927@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: jimse@novell.com Subject: Re: [ldapext] Samba and the password policy draft Cc: ldapext@ietf.org, VBrimhall@novell.com, abartlet@samba.org, samba-technical@samba.org Reply-To: lukeh@PADL.COM Date: Tue, 9 Mar 2004 13:51:45 +1100 Versions: dmail (bsd44) 2.4c/makemail 2.9d X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , >I'm wondering if there's something preventing the use of an NT/LM SASL >mechanism to perform an LDAP SASL bind. Novell is beginning to look at >doing just that and will contribute to the code if it's seen as >beneficial. If this were available, the password policy could still be >enforced by the LDAP server For the record, this exists and is supported by Active Directory -- it is the NTLM SASL mechanism. But, as Andrew pointed out, it buys you nothing with pass-through authentication. >Then for password modifications, there is RFC 3602. Do you think this >is sufficient to update these kinds of passwords? In some cases you only have the user's keys, not their password. Perhaps a control could be defined that extended RFC 3062 to support setting keys. -- Luke _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Mar 8 23:04:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19707 for ; Mon, 8 Mar 2004 23:04:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0YTI-0006Lv-PA; Mon, 08 Mar 2004 23:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0YSR-0006KE-TN for ldapext@optimus.ietf.org; Mon, 08 Mar 2004 23:03:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19605 for ; Mon, 8 Mar 2004 23:03:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0YSO-0006Q0-00 for ldapext@ietf.org; Mon, 08 Mar 2004 23:03:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0YRP-0006Do-00 for ldapext@ietf.org; Mon, 08 Mar 2004 23:02:03 -0500 Received: from [203.17.154.98] (helo=mail.velocitynet.com.au) by ietf-mx with esmtp (Exim 4.12) id 1B0YQO-0005vJ-00 for ldapext@ietf.org; Mon, 08 Mar 2004 23:01:01 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.velocitynet.com.au (Postfix) with ESMTP id 2116C97C2C3; Tue, 9 Mar 2004 15:00:02 +1100 (EST) Received: from mail.velocitynet.com.au ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22630-04; Tue, 9 Mar 2004 14:59:40 +1100 (EST) Received: from yowiee.bartlett.house (177.196.221.203.velocitynet.com.au [203.221.196.177]) by mail.velocitynet.com.au (Postfix) with ESMTP id 1307097C290; Tue, 9 Mar 2004 14:59:40 +1100 (EST) Received: from [192.168.1.12] (abartlet@[192.168.1.12]) by yowiee.bartlett.house (8.12.10/8.12.8) with ESMTP id i2940aDb002610; Tue, 9 Mar 2004 15:00:36 +1100 Subject: Re: [ldapext] Samba and the password policy draft From: Andrew Bartlett To: Luke Howard Cc: jimse@novell.com, ldapext@ietf.org, VBrimhall@novell.com, abartlet@samba.org, Multiple recipients of list SAMBA-TECHNICAL In-Reply-To: <200403090251.NAA01927@au.padl.com> References: <200403090251.NAA01927@au.padl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/mkztZIC1V3wUWrFFV8E" Message-Id: <1078804835.8612.4.camel@piglett.bartlett.house> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Tue, 09 Mar 2004 15:00:35 +1100 X-Virus-Scanned: by amavisd-new at velocitynet.com.au X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , --=-/mkztZIC1V3wUWrFFV8E Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-03-09 at 13:51, Luke Howard wrote: > >I'm wondering if there's something preventing the use of an NT/LM SASL > >mechanism to perform an LDAP SASL bind. Novell is beginning to look at > >doing just that and will contribute to the code if it's seen as > >beneficial. If this were available, the password policy could still be > >enforced by the LDAP server >=20 > For the record, this exists and is supported by Active Directory -- it > is the NTLM SASL mechanism. But, as Andrew pointed out, it buys you > nothing with pass-through authentication. > =20 > >Then for password modifications, there is RFC 3602. Do you think this > >is sufficient to update these kinds of passwords?=20 >=20 > In some cases you only have the user's keys, not their password. Perhaps > a control could be defined that extended RFC 3062 to support setting > keys. Indeed, that would be useful. Could direct setting of those attributes be considered to be that operation? That is already proposed as an allowed way to change userPassword, I think. Andrew Bartlett --=20 Andrew Bartlett abartlet@pcug.org.au Manager, Authentication Subsystems, Samba Team abartlet@samba.org Student Network Administrator, Hawker College abartlet@hawkerc.net http://samba.org http://build.samba.org http://hawkerc.net --=-/mkztZIC1V3wUWrFFV8E Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQBATUFiw6AkmCjZ77cRAktwAKCmg03yRVqa/KMMQ7hf8cBGOefk+wCgs+eY ndvvKWcCFw21eQwBEzEo+PA= =t1RS -----END PGP SIGNATURE----- --=-/mkztZIC1V3wUWrFFV8E-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 9 01:15:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25670 for ; Tue, 9 Mar 2004 01:15:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0aW6-0000A6-6g; Tue, 09 Mar 2004 01:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0aVN-00007D-5Y for ldapext@optimus.ietf.org; Tue, 09 Mar 2004 01:14:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25653 for ; Tue, 9 Mar 2004 01:14:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0aVK-0005B6-00 for ldapext@ietf.org; Tue, 09 Mar 2004 01:14:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0aUR-00052A-00 for ldapext@ietf.org; Tue, 09 Mar 2004 01:13:19 -0500 Received: from au.padl.com ([203.13.32.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0aTZ-0004jD-00 for ldapext@ietf.org; Tue, 09 Mar 2004 01:12:26 -0500 Received: (from lukeh@localhost) by au.padl.com (8.9.3/8.9.3) id RAA06204; Tue, 9 Mar 2004 17:11:47 +1100 (EST) From: Luke Howard Message-Id: <200403090611.RAA06204@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: abartlet@samba.org Subject: Re: [ldapext] Samba and the password policy draft Cc: jimse@novell.com, ldapext@ietf.org, VBrimhall@novell.com, abartlet@samba.org, samba-technical@samba.org Reply-To: lukeh@PADL.COM References: <200403090251.NAA01927@au.padl.com> <1078804835.8612.4.camel@piglett.bartlett.house> Date: Tue, 9 Mar 2004 17:11:46 +1100 Versions: dmail (bsd44) 2.4c/makemail 2.9d X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , >> In some cases you only have the user's keys, not their password. Perhaps >> a control could be defined that extended RFC 3062 to support setting >> keys. > >Indeed, that would be useful. Could direct setting of those attributes >be considered to be that operation? True. A set keys operation, though, would at least abstract the client from caring about how the keys are represented in the directory, and allow the server to enforce constraints that may not be appropriate in the case of a normal directory update. draft-ietf-krb-wg-kerberos-set-passwd-01.txt might be a good place to start -- there was some talk at the Vienna IETF about extending this to LDAP. -- Luke _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 9 03:59:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16122 for ; Tue, 9 Mar 2004 03:59:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0d4n-00038T-Sy; Tue, 09 Mar 2004 03:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0d47-00036o-LB for ldapext@optimus.ietf.org; Tue, 09 Mar 2004 03:58:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16021 for ; Tue, 9 Mar 2004 03:58:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0d45-0001Vm-00 for ldapext@ietf.org; Tue, 09 Mar 2004 03:58:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0d35-0001IG-00 for ldapext@ietf.org; Tue, 09 Mar 2004 03:57:16 -0500 Received: from mail2.rogers.com ([142.146.31.22] helo=mail2.mail.rss.rogers.com) by ietf-mx with esmtp (Exim 4.12) id 1B0d28-0000wY-00 for ldapext@ietf.org; Tue, 09 Mar 2004 03:56:17 -0500 Received: from rssesnexigwa.rci.rogers.ca (rssesnexigwa.rss.rogers.com [142.146.14.121]) by mail2.mail.rss.rogers.com (8.12.10+Sun/8.12.10) with ESMTP id i298lSeB023279; Tue, 9 Mar 2004 03:47:32 -0500 (EST) Received: from mail pickup service by rssesnexigwa.rci.rogers.ca with Microsoft SMTPSVC; Tue, 9 Mar 2004 03:55:40 -0500 Received: from mail3.mail.rss.rogers.com ([142.146.31.20]) by rssesnexigwa.rci.rogers.ca with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Mar 2004 01:12:11 -0500 Received: from lists.samba.org (dp.samba.org [66.70.73.150]) by mail3.mail.rss.rogers.com (8.12.10+Sun/8.12.10) with ESMTP id i2962gkd002553 for ; Tue, 9 Mar 2004 01:02:42 -0500 (EST) Received: from dp.samba.org (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id 1FCEF2C543 for ; Tue, 9 Mar 2004 06:12:16 +0000 (GMT) X-Original-To: samba-technical@samba.org Delivered-To: samba-technical@samba.org Received: from au.padl.com (au.padl.com [203.13.32.1]) by lists.samba.org (Postfix) with ESMTP id 655732C14D; Tue, 9 Mar 2004 06:11:59 +0000 (GMT) Received: (from lukeh@localhost) by au.padl.com (8.9.3/8.9.3) id RAA06204; Tue, 9 Mar 2004 17:11:47 +1100 (EST) From: Luke Howard Message-Id: <200403090611.RAA06204@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: abartlet@samba.org References: <200403090251.NAA01927@au.padl.com> <1078804835.8612.4.camel@piglett.bartlett.house> Date: Tue, 9 Mar 2004 17:11:46 +1100 Versions: dmail (bsd44) 2.4c/makemail 2.9d Cc: VBrimhall@novell.com, abartlet@samba.org, ldapext@ietf.org, samba-technical@samba.org, jimse@novell.com Subject: Re: [ldapext] Samba and the password policy draft X-BeenThere: samba-technical@lists.samba.org X-Mailman-Version: 2.1.3 Precedence: list Reply-To: lukeh@PADL.COM X-OriginalArrivalTime: 09 Mar 2004 06:12:12.0632 (UTC) FILETIME=[76523580:01C4059D] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , >> In some cases you only have the user's keys, not their password. Perhaps >> a control could be defined that extended RFC 3062 to support setting >> keys. > >Indeed, that would be useful. Could direct setting of those attributes >be considered to be that operation? True. A set keys operation, though, would at least abstract the client from caring about how the keys are represented in the directory, and allow the server to enforce constraints that may not be appropriate in the case of a normal directory update. draft-ietf-krb-wg-kerberos-set-passwd-01.txt might be a good place to start -- there was some talk at the Vienna IETF about extending this to LDAP. -- Luke _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 9 04:03:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16361 for ; Tue, 9 Mar 2004 04:03:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0d8f-0003VV-JY; Tue, 09 Mar 2004 04:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0d80-0003Mn-On for ldapext@optimus.ietf.org; Tue, 09 Mar 2004 04:02:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16299 for ; Tue, 9 Mar 2004 04:02:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0d7y-0002Ia-00 for ldapext@ietf.org; Tue, 09 Mar 2004 04:02:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0d6y-00025e-00 for ldapext@ietf.org; Tue, 09 Mar 2004 04:01:17 -0500 Received: from mail2.rogers.com ([142.146.31.22] helo=mail2.mail.rss.rogers.com) by ietf-mx with esmtp (Exim 4.12) id 1B0d5w-0001ls-00 for ldapext@ietf.org; Tue, 09 Mar 2004 04:00:12 -0500 Received: from rssesnexigwa.rci.rogers.ca (rssesnexigwa.rss.rogers.com [142.146.14.121]) by mail2.mail.rss.rogers.com (8.12.10+Sun/8.12.10) with ESMTP id i298pKer025044; Tue, 9 Mar 2004 03:51:34 -0500 (EST) Received: from mail pickup service by rssesnexigwa.rci.rogers.ca with Microsoft SMTPSVC; Tue, 9 Mar 2004 03:59:43 -0500 Received: from mail3.mail.rss.rogers.com ([142.146.31.20]) by rssesnexigwa.rci.rogers.ca with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Mar 2004 23:01:32 -0500 Received: from lists.samba.org (dp.samba.org [66.70.73.150]) by mail3.mail.rss.rogers.com (8.12.10+Sun/8.12.10) with ESMTP id i293q1Ia017656 for ; Mon, 8 Mar 2004 22:52:02 -0500 (EST) Received: from dp.samba.org (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id F40B32C495 for ; Tue, 9 Mar 2004 04:01:35 +0000 (GMT) X-Original-To: samba-technical@samba.org Delivered-To: samba-technical@samba.org Received: from mail.velocitynet.com.au (unknown [203.17.154.98]) by lists.samba.org (Postfix) with ESMTP id 238D32C3E4; Tue, 9 Mar 2004 04:01:09 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.velocitynet.com.au (Postfix) with ESMTP id 2116C97C2C3; Tue, 9 Mar 2004 15:00:02 +1100 (EST) Received: from mail.velocitynet.com.au ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22630-04; Tue, 9 Mar 2004 14:59:40 +1100 (EST) Received: from yowiee.bartlett.house (177.196.221.203.velocitynet.com.au [203.221.196.177]) by mail.velocitynet.com.au (Postfix) with ESMTP id 1307097C290; Tue, 9 Mar 2004 14:59:40 +1100 (EST) Received: from [192.168.1.12] (abartlet@[192.168.1.12]) by yowiee.bartlett.house (8.12.10/8.12.8) with ESMTP id i2940aDb002610; Tue, 9 Mar 2004 15:00:36 +1100 From: Andrew Bartlett To: Luke Howard In-Reply-To: <200403090251.NAA01927@au.padl.com> References: <200403090251.NAA01927@au.padl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/mkztZIC1V3wUWrFFV8E" Message-Id: <1078804835.8612.4.camel@piglett.bartlett.house> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Tue, 09 Mar 2004 15:00:35 +1100 X-Virus-Scanned: by amavisd-new at velocitynet.com.au Cc: VBrimhall@novell.com, abartlet@samba.org, ldapext@ietf.org, Multiple recipients of list SAMBA-TECHNICAL , jimse@novell.com Subject: Re: [ldapext] Samba and the password policy draft X-BeenThere: samba-technical@lists.samba.org X-Mailman-Version: 2.1.3 Precedence: list X-OriginalArrivalTime: 09 Mar 2004 04:01:33.0679 (UTC) FILETIME=[35F0E7F0:01C4058B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , --=-/mkztZIC1V3wUWrFFV8E Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-03-09 at 13:51, Luke Howard wrote: > >I'm wondering if there's something preventing the use of an NT/LM SASL > >mechanism to perform an LDAP SASL bind. Novell is beginning to look at > >doing just that and will contribute to the code if it's seen as > >beneficial. If this were available, the password policy could still be > >enforced by the LDAP server >=20 > For the record, this exists and is supported by Active Directory -- it > is the NTLM SASL mechanism. But, as Andrew pointed out, it buys you > nothing with pass-through authentication. > =20 > >Then for password modifications, there is RFC 3602. Do you think this > >is sufficient to update these kinds of passwords?=20 >=20 > In some cases you only have the user's keys, not their password. Perhaps > a control could be defined that extended RFC 3062 to support setting > keys. Indeed, that would be useful. Could direct setting of those attributes be considered to be that operation? That is already proposed as an allowed way to change userPassword, I think. Andrew Bartlett --=20 Andrew Bartlett abartlet@pcug.org.au Manager, Authentication Subsystems, Samba Team abartlet@samba.org Student Network Administrator, Hawker College abartlet@hawkerc.net http://samba.org http://build.samba.org http://hawkerc.net --=-/mkztZIC1V3wUWrFFV8E Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQBATUFiw6AkmCjZ77cRAktwAKCmg03yRVqa/KMMQ7hf8cBGOefk+wCgs+eY ndvvKWcCFw21eQwBEzEo+PA= =t1RS -----END PGP SIGNATURE----- --=-/mkztZIC1V3wUWrFFV8E-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Mar 12 03:10:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07472 for ; Fri, 12 Mar 2004 03:10:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1hk1-00023V-OL; Fri, 12 Mar 2004 03:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1hjI-00022a-AN for ldapext@optimus.ietf.org; Fri, 12 Mar 2004 03:09:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07430 for ; Fri, 12 Mar 2004 03:09:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1hjE-00003a-00 for ldapext@ietf.org; Fri, 12 Mar 2004 03:09:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1hiI-0007kb-00 for ldapext@ietf.org; Fri, 12 Mar 2004 03:08:15 -0500 Received: from prv-mail20.provo.novell.com ([137.65.81.122]) by ietf-mx with esmtp (Exim 4.12) id 1B1hhf-0007Xl-00 for ldapext@ietf.org; Fri, 12 Mar 2004 03:07:35 -0500 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 12 Mar 2004 01:07:01 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 12 Mar 2004 01:06:31 -0700 From: "Jim Sermersheim" To: , Cc: Subject: Re: [ldapext] Samba and the password policy draft Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part81A09D97.0__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part81A09D97.0__= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>> Andrew Bartlett 3/6/04 6:38:06 PM >>> >What I am looking for is some additional control or operation that may >be used by Samba/Heimdal/etc to say 'a user just logged in, with the >right password', and 'a user just tried to log in with a wrong >password'.=20 I'm toying with the notion of changing the draft such that it describes = password policy decision points, and then refers to those decision points = when talking about how to implement operations like bind and compare. Once = this is done, it should be easy to create new operations (like those you = mentioned) and specify which password policy decision points are invoked = during those new operations. =20 The first thing I noticed when looking at doing this is that the current = wording for bind (and compare) require server implementations to check for = a locked account prior to performing the password comparison. I think we = did this either as an optimization, or because we deemed it important to = always check for the locked account condition. I think it'll be ok to just = make a statement that this condition must be checked whether the password = comparison succeeds or fails. =20 The only reason I bring this up is because the suggested operations above = don't/can't follow the current pattern (unless there's also a 'this user = is going to log in' precheck operation * yuk). =20 Jim --=__Part81A09D97.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>>> Andrew Bartlett <abartlet@samba.org> 3/6/04 = 6:38:06 PM >>>
>What I am looking for is some additional control or operation = that may
>be used by Samba/Heimdal/etc to say 'a user just logged = in, with the
>right password', and 'a user just tried to log in with = a wrong
>password'.

I'm toying with the notion of changing = the draft such that it describes password policy decision points, and then = refers to those decision points when talking about how to implement = operations like bind and compare. Once this is done, it should be easy to = create new operations (like those you mentioned) and specify which = password policy decision points are invoked during those new operations.
 
The first thing I noticed when looking at doing this is that the = current wording for bind (and compare) require server implementations = to check for a locked account prior to performing the password comparison. = I think we did this either as an optimization, or because we deemed it = important to always check for the locked account condition. I think = it'll be ok to just make a statement that this condition must be checked = whether the password comparison succeeds or fails.
 
The only reason I bring this up is because the suggested operations = above don't/can't follow the current pattern (unless there's also a 'this = user is going to log in' precheck operation =97 yuk).
 
Jim
--=__Part81A09D97.0__=-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Mar 15 20:10:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11623 for ; Mon, 15 Mar 2004 20:10:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B335l-0003H6-JJ; Mon, 15 Mar 2004 20:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B335C-0003G9-Iv for ldapext@optimus.ietf.org; Mon, 15 Mar 2004 20:09:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11586 for ; Mon, 15 Mar 2004 20:09:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B335A-0001W2-00 for ldapext@ietf.org; Mon, 15 Mar 2004 20:09:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B334C-0001SX-00 for ldapext@ietf.org; Mon, 15 Mar 2004 20:08:24 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx with esmtp (Exim 4.12) id 1B333X-0001P9-00 for ldapext@ietf.org; Mon, 15 Mar 2004 20:07:43 -0500 Received: from CELLO (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.12.9/8.12.9) with SMTP id i2G17MIB002823 for ; Mon, 15 Mar 2004 19:07:23 -0600 From: "Howard Chu" To: Date: Mon, 15 Mar 2004 17:06:27 -0800 Message-ID: <032601c40af2$f42008c0$8601a8c0@CELLO> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040219150700.803.66001.Mailman@www1.ietf.org> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [ldapext] Re: draft-behera-ldap-password-policy-07.txt Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > -----Original Message----- > >Section 4.3.3, 6.1.1 > >A 0 value for generalizedTime is mentioned. This is > >impossible as 0 is not a valid value. > >We use 0000010100Z. > Nice catch. We use 000001010000Z which is another > representation of the same value. > I'll change the wording to specific the generalizedTime 1st > of Jan 0000, 00h00mn and give a representation of the value. While testing our implementation for OpenLDAP I tripped over a minor problem - if multiple Bind requests for a user are made in rapid succession, there may not be fine enough resolution in the timestamps to distinguish each attempt. So, the pwdFailureTime (for failures) or pwdGraceUseTime (for expired password) attributes will not have an accurate count because the server refuses to store duplicate values in an attribute. It seems that, audit aspects aside, these attributes would be more useful as single-valued integer counters instead of a list of timestamps. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 16 03:04:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16820 for ; Tue, 16 Mar 2004 03:04:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B39YR-0004TD-7y; Tue, 16 Mar 2004 03:04:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B39YH-0004SD-3G for ldapext@optimus.ietf.org; Tue, 16 Mar 2004 03:03:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16765 for ; Tue, 16 Mar 2004 03:03:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B39YD-0006qk-00 for ldapext@ietf.org; Tue, 16 Mar 2004 03:03:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B39XF-0006kI-00 for ldapext@ietf.org; Tue, 16 Mar 2004 03:02:50 -0500 Received: from prv-mail20.provo.novell.com ([137.65.81.122]) by ietf-mx with esmtp (Exim 4.12) id 1B39WS-0006ad-00 for ldapext@ietf.org; Tue, 16 Mar 2004 03:02:00 -0500 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 16 Mar 2004 01:01:31 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 16 Mar 2004 01:01:15 -0700 From: "Jim Sermersheim" To: , Subject: [ldapext] Re: draft-behera-ldap-password-policy-07.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part91B08A5B.1__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part91B08A5B.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit True. For replication purposes, we picked timestamp over integer counters. I suggest we use change sequence numbers (http://www.ietf.org/internet-drafts/draft-sermersheim-ldap-csn-00.txt) instead of timestamps for these. I also noticed that the quoted change below was made to Section 6.1 (bind), but not Section 6.4 (compare), I hope to consolidate these nearly identical sections soon. Jim >>> "Howard Chu" 3/15/04 6:06:27 PM >>> > -----Original Message----- > >Section 4.3.3, 6.1.1 > >A 0 value for generalizedTime is mentioned. This is > >impossible as 0 is not a valid value. > >We use 0000010100Z. > Nice catch. We use 000001010000Z which is another > representation of the same value. > I'll change the wording to specific the generalizedTime 1st > of Jan 0000, 00h00mn and give a representation of the value. While testing our implementation for OpenLDAP I tripped over a minor problem - if multiple Bind requests for a user are made in rapid succession, there may not be fine enough resolution in the timestamps to distinguish each attempt. So, the pwdFailureTime (for failures) or pwdGraceUseTime (for expired password) attributes will not have an accurate count because the server refuses to store duplicate values in an attribute. It seems that, audit aspects aside, these attributes would be more useful as single-valued integer counters instead of a list of timestamps. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__Part91B08A5B.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
True. For replication purposes, we picked timestamp over integer = counters.
 
I suggest we use change sequence numbers (http://www.ietf.org/i= nternet-drafts/draft-sermersheim-ldap-csn-00.txt) instead of = timestamps for these.
 
I also noticed that the quoted change below was made to Section 6.1 = (bind), but not Section 6.4 (compare), I hope to consolidate these nearly = identical sections soon.
 
Jim

>>> "Howard Chu" <hyc@highlandsun.com> = 3/15/04 6:06:27 PM >>>
> -----Original Message-----
> = >Section 4.3.3, 6.1.1
> >A 0 value for generalizedTime is = mentioned. This is
> >impossible as 0 is not a valid value.
>= ; >We use 0000010100Z.

> Nice catch. We use 000001010000Z = which is another
> representation of the same value.
> I'll = change the wording to specific the generalizedTime 1st
> of Jan = 0000, 00h00mn and give a representation of the value.

While testing = our implementation for OpenLDAP I tripped over a minor
problem - if = multiple Bind requests for a user are made in rapid succession,
there = may not be fine enough resolution in the timestamps to distinguish = each
attempt. So, the pwdFailureTime (for failures) or pwdGraceUseTime = (for
expired password) attributes will not have an accurate count = because the
server refuses to store duplicate values in an attribute.
It seems that, audit aspects aside, these attributes would be more = useful as
single-valued integer counters instead of a list of timestamps= .

-- Howard Chu
Chief Architect, Symas Corp. Director, Highland = Sun
http://www.symas.com = http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support


________= _______________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/ldapext
--=__Part91B08A5B.1__=-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 16 06:02:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23699 for ; Tue, 16 Mar 2004 06:02:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3CKf-00022O-Be; Tue, 16 Mar 2004 06:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3CKH-00021p-Au for ldapext@optimus.ietf.org; Tue, 16 Mar 2004 06:01:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23612 for ; Tue, 16 Mar 2004 06:01:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3CKD-0005rr-00 for ldapext@ietf.org; Tue, 16 Mar 2004 06:01:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3CJJ-0005ma-00 for ldapext@ietf.org; Tue, 16 Mar 2004 06:00:37 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1B3CIg-0005gY-00 for ldapext@ietf.org; Tue, 16 Mar 2004 05:59:58 -0500 Received: from odin.France.Sun.COM ([129.157.174.8]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2GAxMWA007629; Tue, 16 Mar 2004 02:59:23 -0800 (PST) Received: from Sun.COM (dhcp-gnb07-211-108 [129.157.211.108]) by odin.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id i2GAxMP08098; Tue, 16 Mar 2004 11:59:22 +0100 (MET) Message-ID: <4056DDD8.3080808@Sun.COM> Date: Tue, 16 Mar 2004 11:58:32 +0100 From: Ludovic Poitou Organization: SUN Microsystems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim CC: hyc@highlandsun.com, ldapext@ietf.org Subject: Re: [ldapext] Re: draft-behera-ldap-password-policy-07.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Using single valued integers is very problematic as there is no increment operation (and reset operation), and thus it doesn't work well with replication. We have several customers that want to have a strict measure of the failed attempts on a distributed directory. I am fine with the use of Change Sequence Numbers (or something similar may be shorter, as GSER really produces big string representations). It may require some specifications on what is a ReplicaID in the case of standalone server. Ludovic. Jim Sermersheim wrote: > True. For replication purposes, we picked timestamp over integer counters. > > I suggest we use change sequence numbers > (http://www.ietf.org/internet-drafts/draft-sermersheim-ldap-csn-00.txt) instead > of timestamps for these. > > I also noticed that the quoted change below was made to Section 6.1 > (bind), but not Section 6.4 (compare), I hope to consolidate these > nearly identical sections soon. > > Jim > > >>> "Howard Chu" 3/15/04 6:06:27 PM >>> > > -----Original Message----- > > >Section 4.3.3, 6.1.1 > > >A 0 value for generalizedTime is mentioned. This is > > >impossible as 0 is not a valid value. > > >We use 0000010100Z. > > > Nice catch. We use 000001010000Z which is another > > representation of the same value. > > I'll change the wording to specific the generalizedTime 1st > > of Jan 0000, 00h00mn and give a representation of the value. > > While testing our implementation for OpenLDAP I tripped over a minor > problem - if multiple Bind requests for a user are made in rapid > succession, > there may not be fine enough resolution in the timestamps to > distinguish each > attempt. So, the pwdFailureTime (for failures) or pwdGraceUseTime (for > expired password) attributes will not have an accurate count because the > server refuses to store duplicate values in an attribute. > > It seems that, audit aspects aside, these attributes would be more > useful as > single-valued integer counters instead of a list of timestamps. > > -- Howard Chu > Chief Architect, Symas Corp. Director, Highland Sun > _http://www.symas.com _ > _http://highlandsun.com/hyc_ > Symas: Premier OpenSource Development and Support > > > _______________________________________________ > Ldapext mailing list > _Ldapext@ietf.org _ > _https://www1.ietf.org/mailman/listinfo/ldapext_ -- Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 16 10:31:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06528 for ; Tue, 16 Mar 2004 10:31:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3GX0-0008Qf-EL; Tue, 16 Mar 2004 10:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3GWj-0008PQ-Nk for ldapext@optimus.ietf.org; Tue, 16 Mar 2004 10:30:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06514 for ; Tue, 16 Mar 2004 10:30:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3GWh-0005T0-00 for ldapext@ietf.org; Tue, 16 Mar 2004 10:30:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3GVr-0005PG-00 for ldapext@ietf.org; Tue, 16 Mar 2004 10:29:52 -0500 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B3GVQ-0005Kh-00 for ldapext@ietf.org; Tue, 16 Mar 2004 10:29:25 -0500 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i2GFTEMs005989; Tue, 16 Mar 2004 15:29:14 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040316071629.04852ed8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 16 Mar 2004 07:28:59 -0800 To: Ludovic Poitou From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Re: draft-behera-ldap-password-policy-07.txt Cc: Jim Sermersheim , hyc@highlandsun.com, ldapext@ietf.org In-Reply-To: <4056DDD8.3080808@Sun.COM> References: <4056DDD8.3080808@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 02:58 AM 3/16/2004, Ludovic Poitou wrote: >Using single valued integers is very problematic as there is no increment operation (and reset operation), and thus it doesn't work well with replication. Replicating values due to non-user modifications is also problematic. It seems to me that an attacker could abuse distributed directories supporting such? Also, if this is a master-provided attribute, it seems you need a mechanism for shadow servers communicate to the master that a bind has failed? Also, doesn't this mean you can attack all the shadows at will until the master communicates that the account is locked? I also note that giving notice that an 'account' is 'locked' is helpful to an attacker. Let's them know they need to move onto another account for a while, or can be used by the attacker to lock out a particular user, or to DoS the directory administrator with support calls from locked out users. I think we need to consider alternatives to locking the account to hinder dictionary/exhaustive attack upon user's password. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 16 11:21:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08857 for ; Tue, 16 Mar 2004 11:21:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3HJN-0004wX-Fj; Tue, 16 Mar 2004 11:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3HIS-0004v1-7B for ldapext@optimus.ietf.org; Tue, 16 Mar 2004 11:20:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08766 for ; Tue, 16 Mar 2004 11:20:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3HIR-0002AY-00 for ldapext@ietf.org; Tue, 16 Mar 2004 11:20:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3HHY-00023E-00 for ldapext@ietf.org; Tue, 16 Mar 2004 11:19:08 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1B3HGp-0001wP-00 for ldapext@ietf.org; Tue, 16 Mar 2004 11:18:23 -0500 Received: from odin.France.Sun.COM ([129.157.174.8]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2GGIJex023756; Tue, 16 Mar 2004 09:18:20 -0700 (MST) Received: from Sun.COM (dhcp-gnb07-211-108 [129.157.211.108]) by odin.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id i2GGIJP20175; Tue, 16 Mar 2004 17:18:19 +0100 (MET) Message-ID: <40572898.20504@Sun.COM> Date: Tue, 16 Mar 2004 17:17:28 +0100 From: Ludovic Poitou Organization: SUN Microsystems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Jim Sermersheim , hyc@highlandsun.com, ldapext@ietf.org Subject: Re: [ldapext] Re: draft-behera-ldap-password-policy-07.txt References: <4056DDD8.3080808@Sun.COM> <6.0.1.1.0.20040316071629.04852ed8@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040316071629.04852ed8@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >At 02:58 AM 3/16/2004, Ludovic Poitou wrote: > > >>Using single valued integers is very problematic as there is no increment operation (and reset operation), and thus it doesn't work well with replication. >> >> > >Replicating values due to non-user modifications is also >problematic. It seems to me that an attacker could abuse >distributed directories supporting such? > Correct. > Also, if this >is a master-provided attribute, it seems you need a >mechanism for shadow servers communicate to the master >that a bind has failed? > Correct. > Also, doesn't this mean you can >attack all the shadows at will until the master communicates >that the account is locked? > > That is an implementation issue (one can apply the change locally and communicate it to the Master). >I also note that giving notice that an 'account' is 'locked' >is helpful to an attacker. Let's them know they need to >move onto another account for a while, or can be used by >the attacker to lock out a particular user, or to DoS >the directory administrator with support calls from locked >out users. > > I agree... Implementation should be free to return or not the control giving notice that the 'account' is 'locked' >I think we need to consider alternatives to locking the >account to hinder dictionary/exhaustive attack upon user's >password. > > > What is the current state of the art with regards to dictionary attack protection ? Except keeping answering invalid credentials without actually doing anything, I don't have ideas... Ludovic. >Kurt > > > -- Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 16 13:13:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14599 for ; Tue, 16 Mar 2004 13:13:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3J3k-0006Kf-Rv; Tue, 16 Mar 2004 13:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3J3d-0006J7-Th for ldapext@optimus.ietf.org; Tue, 16 Mar 2004 13:12:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14576 for ; Tue, 16 Mar 2004 13:12:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3J3b-0006K6-00 for ldapext@ietf.org; Tue, 16 Mar 2004 13:12:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3J2h-0006Fy-00 for ldapext@ietf.org; Tue, 16 Mar 2004 13:11:55 -0500 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B3J2U-0006BO-00 for ldapext@ietf.org; Tue, 16 Mar 2004 13:11:42 -0500 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i2GIBdMs008091; Tue, 16 Mar 2004 18:11:39 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040316083937.0492f820@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 16 Mar 2004 10:11:24 -0800 To: Ludovic Poitou From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Re: draft-behera-ldap-password-policy-07.txt Cc: Jim Sermersheim , hyc@highlandsun.com, ldapext@ietf.org In-Reply-To: <40572898.20504@Sun.COM> References: <4056DDD8.3080808@Sun.COM> <6.0.1.1.0.20040316071629.04852ed8@127.0.0.1> <40572898.20504@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 08:17 AM 3/16/2004, Ludovic Poitou wrote: >What is the current state of the art with regards to dictionary attack protection ? Except keeping answering invalid credentials without actually doing anything, I don't have ideas... I think the current state of concern is that one has to be very careful in defending dictionary attacks upon the users' credentials as often the defensive measures open the service to higher risk attacks, such as DoS attacks, or actually aid dictionary attackers. In regards to the latter, it seems this proposal seems to focus in on attacks to a particular known user's password. The proposal seems to give away information that would be useful in attacks on sets of users (including the set of users previously unknown to the attacker). In particular, the proposal aides the attacker in determine which of the possible users are valid. Also, the proposal seems to assume the attack will have an inner loop which varies the password. If the inner loop actually varied the user name, the proposal may be ineffective. In regards to the former, the mechanism is clearly open to DoS abuses upon individual users, the service at a particular server, the (distributed) service in general, and support centers. Not only is the mechanism is kind enough to lock out accounts for the attacker, it kind enough to deal her when they are locked out (so the attacker can move on to locking another account). Anways, I think it would wiser for servers to just return invalidCredentials when the credentials are invalid (and have credentials which have significant entropy), possibly with an exponential delay to slow retries (and a policy that no one connection can have multiple bind requests outstanding). However, even insertion of delays can be used by attackers in denying service. I think the state of the art lies in Intrusion Detection Systems. That is, systems which take information about events, automagically analyze these for possible intrusion attempts, and then take immediate action (notify admin, advise service take some defensive action, etc.) based upon local policy information, and provide tools for subsequent investigation and actions. Of course, the state of art in DoS is to attack IDS systems. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 16 13:41:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17522 for ; Tue, 16 Mar 2004 13:41:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3JUr-0000n2-W6; Tue, 16 Mar 2004 13:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3JUo-0000mG-6V for ldapext@optimus.ietf.org; Tue, 16 Mar 2004 13:40:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17455 for ; Tue, 16 Mar 2004 13:40:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3JUl-0002gb-00 for ldapext@ietf.org; Tue, 16 Mar 2004 13:40:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3JTp-0002YV-00 for ldapext@ietf.org; Tue, 16 Mar 2004 13:39:58 -0500 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B3JSx-0002Qm-00 for ldapext@ietf.org; Tue, 16 Mar 2004 13:39:03 -0500 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i2GId1Ms008479; Tue, 16 Mar 2004 18:39:01 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040316102444.02c37258@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 16 Mar 2004 10:38:46 -0800 To: Ludovic Poitou From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Re: draft-behera-ldap-password-policy-07.txt Cc: Jim Sermersheim , hyc@highlandsun.com, ldapext@ietf.org In-Reply-To: <40572898.20504@Sun.COM> References: <4056DDD8.3080808@Sun.COM> <6.0.1.1.0.20040316071629.04852ed8@127.0.0.1> <40572898.20504@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 08:17 AM 3/16/2004, Ludovic Poitou wrote: >> Also, doesn't this mean you can >>attack all the shadows at will until the master communicates >>that the account is locked? >> >That is an implementation issue (one can apply the change locally and communicate it to the Master). Doesn't this go against your' user's desire to have a strict lock out on N retries policy across the service? I mean, if implementations are free to local retries counts, than cannot those be abused to get retries than the policy allowed? Ignoring DoS attacks in this area, is there a scaling problem here? We have deployments involving large numbers of replicas where maintain policy state information on a context wide basis would be prohibitively expensive. It seems to me that it would be better to define any state information to be DSA-specific, but with a comment saying that DSAs may agree to share state information but that the how to that sharing could be performed is beyond the scope of this document. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 16 14:02:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18541 for ; Tue, 16 Mar 2004 14:02:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3JpA-00021n-6J; Tue, 16 Mar 2004 14:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Jp4-00021G-13 for ldapext@optimus.ietf.org; Tue, 16 Mar 2004 14:01:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18526 for ; Tue, 16 Mar 2004 14:01:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Jp1-0004kE-00 for ldapext@ietf.org; Tue, 16 Mar 2004 14:01:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3JoB-0004g7-00 for ldapext@ietf.org; Tue, 16 Mar 2004 14:00:59 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx with esmtp (Exim 4.12) id 1B3Jnb-0004bE-00 for ldapext@ietf.org; Tue, 16 Mar 2004 14:00:23 -0500 Received: from CELLO (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.12.9/8.12.9) with SMTP id i2GJ041h021949; Tue, 16 Mar 2004 13:00:04 -0600 From: "Howard Chu" To: "'Kurt D. Zeilenga'" , "'Ludovic Poitou'" Cc: "'Jim Sermersheim'" , Subject: RE: [ldapext] Re: draft-behera-ldap-password-policy-07.txt Date: Tue, 16 Mar 2004 10:59:17 -0800 Message-ID: <034201c40b88$cf3f5ab0$8601a8c0@CELLO> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <6.0.1.1.0.20040316102444.02c37258@127.0.0.1> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > At 08:17 AM 3/16/2004, Ludovic Poitou wrote: > >> Also, doesn't this mean you can > >>attack all the shadows at will until the master communicates > >>that the account is locked? > >> > >That is an implementation issue (one can apply the change > locally and communicate it to the Master). > > Doesn't this go against your' user's desire to have a strict > lock out on N retries policy across the service? I mean, if > implementations are free to local retries counts, than cannot > those be abused to get retries than the policy allowed? Another similar case is for a pool of servers behind a DNS round-robin scheme or a load balancer... > Ignoring DoS attacks in this area, is there a scaling problem > here? > > We have deployments involving large numbers of replicas > where maintain policy state information on a context > wide basis would be prohibitively expensive. There's definitely the potential here for Bind requests on a single server to tie up resources on all cooperating servers as the policy attributes get replicated around. In a single-master case it would make more sense for the read-only replicas to chain the Binds to the master rather than process them locally, and keep the policy attributes only on the master. > It seems to me that it would be better to define any state > information to be DSA-specific, but with a comment saying > that DSAs may agree to share state information but that > the how to that sharing could be performed is beyond the > scope of this document. As a sanity check it would be good to have a "Replication/Distribution Considerations" section (somewhat like the current section 9) that was Informative (not normative) highlighting some of the pros and cons of various approaches. It always bugs me to see a document punt with "there are problems here" without listing the problems... -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 16 14:45:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20273 for ; Tue, 16 Mar 2004 14:45:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3KUo-0005Iv-N8; Tue, 16 Mar 2004 14:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3KUk-0005IJ-Ur for ldapext@optimus.ietf.org; Tue, 16 Mar 2004 14:44:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20237 for ; Tue, 16 Mar 2004 14:44:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3KUi-00011Q-00 for ldapext@ietf.org; Tue, 16 Mar 2004 14:44:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3KTm-0000vu-00 for ldapext@ietf.org; Tue, 16 Mar 2004 14:43:58 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1B3KT1-0000mk-00 for ldapext@ietf.org; Tue, 16 Mar 2004 14:43:11 -0500 Received: from odin.France.Sun.COM ([129.157.174.8]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2GJgWWA023815; Tue, 16 Mar 2004 11:42:33 -0800 (PST) Received: from Sun.COM (vpn-129-150-116-19.UK.Sun.COM [129.150.116.19]) by odin.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id i2GJgUP10320; Tue, 16 Mar 2004 20:42:31 +0100 (MET) Message-ID: <40575875.8080504@Sun.COM> Date: Tue, 16 Mar 2004 20:41:41 +0100 From: Ludovic Poitou Organization: SUN Microsystems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Howard Chu CC: "'Kurt D. Zeilenga'" , "'Jim Sermersheim'" , ldapext@ietf.org Subject: Re: [ldapext] Re: draft-behera-ldap-password-policy-07.txt References: <034201c40b88$cf3f5ab0$8601a8c0@CELLO> In-Reply-To: <034201c40b88$cf3f5ab0$8601a8c0@CELLO> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Howard Chu wrote: >>-----Original Message----- >>From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >> >> > > > >>At 08:17 AM 3/16/2004, Ludovic Poitou wrote: >> >> >>>>Also, doesn't this mean you can >>>>attack all the shadows at will until the master communicates >>>>that the account is locked? >>>> >>>> >>>> >>>That is an implementation issue (one can apply the change >>> >>> >>locally and communicate it to the Master). >> >>Doesn't this go against your' user's desire to have a strict >>lock out on N retries policy across the service? I mean, if >>implementations are free to local retries counts, than cannot >>those be abused to get retries than the policy allowed? >> >> > >Another similar case is for a pool of servers behind a DNS round-robin scheme >or a load balancer... > > > >>Ignoring DoS attacks in this area, is there a scaling problem >>here? >> >>We have deployments involving large numbers of replicas >>where maintain policy state information on a context >>wide basis would be prohibitively expensive. >> >> > >There's definitely the potential here for Bind requests on a single server to >tie up resources on all cooperating servers as the policy attributes get >replicated around. In a single-master case it would make more sense for the >read-only replicas to chain the Binds to the master rather than process them >locally, and keep the policy attributes only on the master. > > I agree that it may be very resource consuming, but it mainly depend on the rate of authentication request. However, I think that this is a deployement choice. We don't want to mandate the failure attempts to be replication, but we don't want to prevent it either. The Sun Directory Server password policy currently uses single valued integer for the failure count and we are seeing major issues in some deployements, and numerous customers requesting a single lockout counter (although this is beyond dictionary attack protection). > > >>It seems to me that it would be better to define any state >>information to be DSA-specific, but with a comment saying >>that DSAs may agree to share state information but that >>the how to that sharing could be performed is beyond the >>scope of this document. >> >> > >As a sanity check it would be good to have a "Replication/Distribution >Considerations" section (somewhat like the current section 9) that was >Informative (not normative) highlighting some of the pros and cons of various >approaches. It always bugs me to see a document punt with "there are problems >here" without listing the problems... > > I agree. Will think of how to change section 9. Ludovic > -- Howard Chu > Chief Architect, Symas Corp. Director, Highland Sun > http://www.symas.com http://highlandsun.com/hyc > Symas: Premier OpenSource Development and Support > > > -- Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 16 19:01:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06884 for ; Tue, 16 Mar 2004 19:01:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3OUX-0004bs-OS; Tue, 16 Mar 2004 19:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3OU4-0004bS-7l for ldapext@optimus.ietf.org; Tue, 16 Mar 2004 19:00:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06813 for ; Tue, 16 Mar 2004 19:00:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3OU1-0006kF-00 for ldapext@ietf.org; Tue, 16 Mar 2004 19:00:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3OSq-0006dR-00 for ldapext@ietf.org; Tue, 16 Mar 2004 18:59:16 -0500 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1B3OSH-0006VB-00 for ldapext@ietf.org; Tue, 16 Mar 2004 18:58:41 -0500 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.5.9) id ; Wed, 17 Mar 2004 10:48:26 +1100 Received: (qmail 26656 invoked from network); 16 Mar 2004 23:58:06 -0000 Received: from unknown (HELO edmund.mtwav.adacel.com.au) (10.32.24.160) by nexus.adacel.com with SMTP; 16 Mar 2004 23:58:06 -0000 Received: from adacel.com (xenon.mtwav.adacel.com.au [10.32.24.164]) by edmund.mtwav.adacel.com.au (8.11.6/8.11.6) with ESMTP id i2GNw6F22380; Wed, 17 Mar 2004 10:58:06 +1100 Message-ID: <4057948D.2080306@adacel.com> Date: Wed, 17 Mar 2004 10:58:05 +1100 From: Mark Ennis User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Howard Chu CC: ldapext@ietf.org Subject: Re: [ldapext] Re: draft-behera-ldap-password-policy-07.txt References: <032601c40af2$f42008c0$8601a8c0@CELLO> In-Reply-To: <032601c40af2$f42008c0$8601a8c0@CELLO> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit We ran into a similar problem when implementing X.500 replication protocols. Our solution was to increase the resolution of the timestamps we generate to millisecond resolution. This solved immediate problems and, as machines speed up, we can increase the resolution as required. I am not aware of any limit on the resolution of fractional seconds which can be represented in the GeneralizedTime representation. The pwdFailureTime can be used to identify how many failed logins occurred in a particular period of time, replacing it with a counter will be an insufficient alternative. - Mark. Howard Chu wrote: >>-----Original Message----- >> >>>Section 4.3.3, 6.1.1 >>>A 0 value for generalizedTime is mentioned. This is >>>impossible as 0 is not a valid value. >>>We use 0000010100Z. > > >>Nice catch. We use 000001010000Z which is another >>representation of the same value. >>I'll change the wording to specific the generalizedTime 1st >>of Jan 0000, 00h00mn and give a representation of the value. > > > While testing our implementation for OpenLDAP I tripped over a minor > problem - if multiple Bind requests for a user are made in rapid succession, > there may not be fine enough resolution in the timestamps to distinguish each > attempt. So, the pwdFailureTime (for failures) or pwdGraceUseTime (for > expired password) attributes will not have an accurate count because the > server refuses to store duplicate values in an attribute. > > It seems that, audit aspects aside, these attributes would be more useful as > single-valued integer counters instead of a list of timestamps. > > -- Howard Chu > Chief Architect, Symas Corp. Director, Highland Sun > http://www.symas.com http://highlandsun.com/hyc > Symas: Premier OpenSource Development and Support > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 16 19:11:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07191 for ; Tue, 16 Mar 2004 19:11:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3OeD-0005B3-L5; Tue, 16 Mar 2004 19:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3OdS-00059b-SE for ldapext@optimus.ietf.org; Tue, 16 Mar 2004 19:10:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07146 for ; Tue, 16 Mar 2004 19:10:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3OdP-0007jr-00 for ldapext@ietf.org; Tue, 16 Mar 2004 19:10:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3OcQ-0007dP-00 for ldapext@ietf.org; Tue, 16 Mar 2004 19:09:10 -0500 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1B3Oba-0007S5-00 for ldapext@ietf.org; Tue, 16 Mar 2004 19:08:18 -0500 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.5.9) id ; Wed, 17 Mar 2004 10:58:07 +1100 Received: (qmail 27580 invoked from network); 17 Mar 2004 00:07:47 -0000 Received: from unknown (HELO edmund.mtwav.adacel.com.au) (10.32.24.160) by nexus.adacel.com with SMTP; 17 Mar 2004 00:07:47 -0000 Received: from adacel.com (xenon.mtwav.adacel.com.au [10.32.24.164]) by edmund.mtwav.adacel.com.au (8.11.6/8.11.6) with ESMTP id i2H07lF22433; Wed, 17 Mar 2004 11:07:47 +1100 Message-ID: <405796D2.7080805@adacel.com> Date: Wed, 17 Mar 2004 11:07:46 +1100 From: Mark Ennis User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim CC: hyc@highlandsun.com, ldapext@ietf.org Subject: Re: [ldapext] Re: draft-behera-ldap-password-policy-07.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'd discourage the use of change sequence numbers as they add extraneous information, specifically replicaID and changeCount, which is not relevant to the problem being addressed. - Mark. Jim Sermersheim wrote: > True. For replication purposes, we picked timestamp over integer counters. > > I suggest we use change sequence numbers > (http://www.ietf.org/internet-drafts/draft-sermersheim-ldap-csn-00.txt) instead > of timestamps for these. > > I also noticed that the quoted change below was made to Section 6.1 > (bind), but not Section 6.4 (compare), I hope to consolidate these > nearly identical sections soon. > > Jim > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 16 21:48:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14338 for ; Tue, 16 Mar 2004 21:48:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3R69-00072v-5J; Tue, 16 Mar 2004 21:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3R63-0006ya-L8 for ldapext@optimus.ietf.org; Tue, 16 Mar 2004 21:47:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14302 for ; Tue, 16 Mar 2004 21:47:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3R60-0001h9-00 for ldapext@ietf.org; Tue, 16 Mar 2004 21:47:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3R4a-0001ah-00 for ldapext@ietf.org; Tue, 16 Mar 2004 21:46:25 -0500 Received: from prv-mail20.provo.novell.com ([137.65.81.122]) by ietf-mx with esmtp (Exim 4.12) id 1B3R3p-0001T7-00 for ldapext@ietf.org; Tue, 16 Mar 2004 21:45:37 -0500 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 16 Mar 2004 19:45:07 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 16 Mar 2004 19:44:45 -0700 From: "Jim Sermersheim" To: Cc: , Subject: Re: [ldapext] Re: draft-behera-ldap-password-policy-07.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part4968538D.2__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part4968538D.2__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit While your earlier suggestion of using fractions of seconds seems a better fit for single-master systems, CSNs are really the only way that I know of to guarantee non-duplication of incrementing values in a multi-master system. In these systems, the replicaID is significant. If we wish to ignore multi-master systems, then an integer counter works fine. As a side note, I believe that in most (or all) systems, either the CSN timeCount or changeCount is extraneous. They were both needed to appease two different schools of thought on the ordering of the values. >>> Mark Ennis 3/16/04 5:07:46 PM >>> I'd discourage the use of change sequence numbers as they add extraneous information, specifically replicaID and changeCount, which is not relevant to the problem being addressed. - Mark. Jim Sermersheim wrote: > True. For replication purposes, we picked timestamp over integer counters. > > I suggest we use change sequence numbers > (http://www.ietf.org/internet-drafts/draft-sermersheim-ldap-csn-00.txt) instead > of timestamps for these. > > I also noticed that the quoted change below was made to Section 6.1 > (bind), but not Section 6.4 (compare), I hope to consolidate these > nearly identical sections soon. > > Jim > --=__Part4968538D.2__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
While your earlier suggestion of using fractions of seconds seems a = better fit for single-master systems, CSNs are really the only way that I = know of to guarantee non-duplication of incrementing values in a multi-mast= er system. In these systems, the replicaID is significant. If we wish to = ignore multi-master systems, then an integer counter works fine.
 
As a side note, I believe that in most (or all) systems, either the = CSN timeCount or changeCount is extraneous. They were both needed to = appease two different schools of thought on the ordering of the values.


>>> Mark Ennis <mark.ennis@adacel.com> 3/16/04 = 5:07:46 PM >>>
I'd discourage the use of change sequence = numbers as they add extraneous
information, specifically replicaID and = changeCount, which is not
relevant to the problem being addressed.
<= BR>- Mark.

Jim Sermersheim wrote:

> True. For replication = purposes, we picked timestamp over integer counters.
>
> I = suggest we use change sequence numbers
> (http://www.ietf.org/intern= et-drafts/draft-sermersheim-ldap-csn-00.txt) instead
> of timestamps= for these.
>
> I also noticed that the quoted change below = was made to Section 6.1
> (bind), but not Section 6.4 (compare), I = hope to consolidate these
> nearly identical sections soon.
> =
> Jim
>

--=__Part4968538D.2__=-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 16 22:41:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16692 for ; Tue, 16 Mar 2004 22:41:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3RvS-0002Cd-9K; Tue, 16 Mar 2004 22:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Rui-0002BV-Cn for ldapext@optimus.ietf.org; Tue, 16 Mar 2004 22:40:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16633 for ; Tue, 16 Mar 2004 22:40:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Ruf-0007VU-00 for ldapext@ietf.org; Tue, 16 Mar 2004 22:40:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Rtf-0007Pg-00 for ldapext@ietf.org; Tue, 16 Mar 2004 22:39:11 -0500 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1B3Rt2-0007ES-00 for ldapext@ietf.org; Tue, 16 Mar 2004 22:38:32 -0500 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.5.9) id ; Wed, 17 Mar 2004 14:27:57 +1100 Received: (qmail 15822 invoked from network); 17 Mar 2004 03:37:39 -0000 Received: from unknown (HELO edmund.mtwav.adacel.com.au) (10.32.24.160) by nexus.adacel.com with SMTP; 17 Mar 2004 03:37:39 -0000 Received: from adacel.com (xenon.mtwav.adacel.com.au [10.32.24.164]) by edmund.mtwav.adacel.com.au (8.11.6/8.11.6) with ESMTP id i2H3bdF24735; Wed, 17 Mar 2004 14:37:39 +1100 Message-ID: <4057C800.6060009@adacel.com> Date: Wed, 17 Mar 2004 14:37:36 +1100 From: Mark Ennis User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim CC: hyc@highlandsun.com, ldapext@ietf.org Subject: Re: [ldapext] Re: draft-behera-ldap-password-policy-07.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: > While your earlier suggestion of using fractions of seconds seems a > better fit for single-master systems, CSNs are really the only way that > I know of to guarantee non-duplication of incrementing values in a > multi-master system. In these systems, the replicaID is significant. I see your point. It would be useful if the ASN.1 definition of the CSN defined the replicaID and possibly both counters as optional (or with default values) if they are to be used in an environment designed for both replication and stand-alone systems. > If we wish to ignore multi-master systems, then an integer counter works fine. An integer counter does not allow determination of how many failures have occurred within a specified period of time, which I believe is one of the properties of the password policy. > > As a side note, I believe that in most (or all) systems, either the CSN > timeCount or changeCount is extraneous. They were both needed to appease > two different schools of thought on the ordering of the values. > > > >>> Mark Ennis 3/16/04 5:07:46 PM >>> > I'd discourage the use of change sequence numbers as they add extraneous > information, specifically replicaID and changeCount, which is not > relevant to the problem being addressed. > > - Mark. > > Jim Sermersheim wrote: > > > True. For replication purposes, we picked timestamp over integer > counters. > > > > I suggest we use change sequence numbers > > > (http://www.ietf.org/internet-drafts/draft-sermersheim-ldap-csn-00.txt) > instead > > of timestamps for these. > > > > I also noticed that the quoted change below was made to Section 6.1 > > (bind), but not Section 6.4 (compare), I hope to consolidate these > > nearly identical sections soon. > > > > Jim > > > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Mar 18 19:56:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20525 for ; Thu, 18 Mar 2004 19:56:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B48Ir-0002JE-3h; Thu, 18 Mar 2004 19:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B48IZ-0002Ic-4M for ldapext@optimus.ietf.org; Thu, 18 Mar 2004 19:55:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20508 for ; Thu, 18 Mar 2004 19:55:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B48IX-0005AS-00 for ldapext@ietf.org; Thu, 18 Mar 2004 19:55:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B48Hb-00057X-00 for ldapext@ietf.org; Thu, 18 Mar 2004 19:54:43 -0500 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B48Gt-00055R-00 for ldapext@ietf.org; Thu, 18 Mar 2004 19:53:59 -0500 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i2J0r0Ms057124; Fri, 19 Mar 2004 00:53:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040318164440.04c61140@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 18 Mar 2004 16:52:41 -0800 To: Mark Ennis From: "Kurt D. Zeilenga" Cc: Jim Sermersheim , hyc@highlandsun.com, ldapext@ietf.org In-Reply-To: <4057C800.6060009@adacel.com> References: <4057C800.6060009@adacel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [ldapext] CSNs (was: draft-behera-ldap-password-policy-07.txt) [ldapext] Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 07:37 PM 3/16/2004, Mark Ennis wrote: >I see your point. It would be useful if the ASN.1 definition of the CSN defined the replicaID and possibly both counters as optional (or with default values) if they are to be used in an environment designed for both replication and stand-alone systems. I suggest defaulting them each (replicaID and both counters) to zero. I think making them optional would unnecessarily complicate comparison logic. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Sat Mar 20 14:59:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21722 for ; Sat, 20 Mar 2004 14:59:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4mcg-0003qT-8r; Sat, 20 Mar 2004 14:59:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4mP6-00031h-SB for ldapext@optimus.ietf.org; Sat, 20 Mar 2004 14:45:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21298 for ; Sat, 20 Mar 2004 14:45:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4mP4-0007i2-00 for ldapext@ietf.org; Sat, 20 Mar 2004 14:45:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4mO7-0007cc-00 for ldapext@ietf.org; Sat, 20 Mar 2004 14:44:08 -0500 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B4mNq-0007XC-00 for ldapext@ietf.org; Sat, 20 Mar 2004 14:43:50 -0500 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i2KJhiMs091582 for ; Sat, 20 Mar 2004 19:43:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040319095039.04bce2c0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 20 Mar 2004 11:43:48 -0800 To: ldapext@ietf.org From: "Kurt D. Zeilenga" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [ldapext] concerns re: draft-behera-ldap-password-policy-07.txt Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , I just finished a quick read of this proposal, and have a number of concerns. I think this premise put forth by this document that retry lockouts mechanism will significantly mitigate against dictionary attacks is somewhat flawed. This lockout is particularly weak in defending dictionary attacks (and prone to DoS attack) as it is based solely on a per-user retry count. Such counters target the user, and not necessarily the attacker. An attacker can easily avoid such a retry (regardless of whether notice is given or not) and, if notice is given, the notice can clearly benefit the attacker. It's my belief that such lockouts are more likely to be used in mounting a denial of service attack (upon the user, the directory service (including replication), upon the support staff/infrastructure) then they will ever be used to effectively stop/slow dictionary attacks. I think it better for any authentication failure to result in a constant message (same code, diag text, etc.) regardless of the reason for failure. And, as attackers may be able to discern the nature of failure by how much time it takes for the server to respond, to take the same amount of time (by delaying response for fast failures) in responding to failed authentication attempts. Also, inserting delay in to hinder dictionary attacks could also be useful. However, I note, inserting any delay implies the server has to maintain the connections/operations for longer periods of time, and that, in itself, could open the server to an DoS attack. I am also concerned by this I-D use of controls attached to bind requests and responses. These controls are only usable (in a secure fashion) when adequate data security services are in place. Aside from this meaning that implementations supporting these controls MUST be capable of protecting them with TLS (though deployers can protect them by other means if they choose), this means that implementations MUST be capable of using TLS with DIGEST-MD5. That's problematic requirement as it leads to multiple security layers. Aside from being redundant in some cases, supporting multiple security layers can be quite difficult. Now the argument I suspect will be voiced is that this policy mechanism is more intended for use with simple bind's password mechanism. But given that DIGEST-MD5 is LDAP's mandatory-to-implement mechanism, I think it appropriate for any standard track LDAP password policy mechanism should be specially designed with it in mind. I also noticed that the document doesn't distinguish between the "directory (server) administrator", the "(password) policy administrator", and the "password administrator". The document says that anyone who can administrate passwords is considered a directory administrator. While a directory administrator can generally administrate passwords, it is follow that everyone who can administrate passwords is a directory administrator. (For instance, my manager can reset my directory password, but he's not the directory administrator.) And I think the security considerations section needs to be flushed out more. For instance, it doesn't discuss that these controls may expose additional information, some of which might be useful to an attacker. Also, it seems an attacker could have lots of fun adding, deleting, and modifying these controls. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext