From ldapext-bounces@ietf.org Tue Dec 27 07:52:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErEJH-0001iR-PA; Tue, 27 Dec 2005 07:52:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErEJG-0001hy-Ns for ldapext@megatron.ietf.org; Tue, 27 Dec 2005 07:52:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12100 for ; Tue, 27 Dec 2005 07:51:02 -0500 (EST) Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErEN6-0002Nr-Lv for ldapext@ietf.org; Tue, 27 Dec 2005 07:56:09 -0500 Received: from 192.168.1.199 (host40-89.pool8172.interbusiness.it [81.72.89.40]) (authenticated bits=0) by mail.sys-net.it (8.13.3/8.13.3) with ESMTP id jBRCpL49025959 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 27 Dec 2005 13:51:21 +0100 From: Pierangelo Masarati To: ldapext@ietf.org Content-Type: text/plain Date: Tue, 27 Dec 2005 13:58:17 +0100 Message-Id: <1135688297.3650.7.camel@ando> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.1 (mail.sys-net.it [194.244.21.114]); Tue, 27 Dec 2005 13:51:22 +0100 (CET) X-SysNet-MailScanner-Information: postmaster@sys-net.it X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: 7bit Cc: Alexey Melnikov Subject: [ldapext] Interaction of with authentication applications X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Dear all, Howard Chu and I, of the OpenLDAP Project, and Alexey Melnikov of Cyrus SASL have been chatting about the issues of making password-based SASL mechs aware and respectful of any Password Policy mechanism implemented at the DSA that contains the passwords, and used by the SASL mechanisms by way of auxprop lookup. I'll briefly summarize the private discussion we had, and then expose my suggestions for a possible evolution of draft-behera-ldap-password-policy. Auxprop lookup consists in looking up the credentials and performing the authentication outside of the DSA. Currently, Cyrus SASL can lookup credentials from a DSA by performing a WhoAmI extended operation to determine the DN of the entry corresponding to a user, and then looking up the auxprops by a search with that DN as base and a baseScope. All the operations are performed using an administrative identity, which is supposed to have read access to the auxprops, including the password. Password policy enforcement would need to be either essentially delegated to the SASL auxprop, in a cooperative agreement with the DSA, and giving up with respect to some features, or split in two phases, again under some cooperative agreement between the DSA and the application: the lookup of the password, which would be subjected to constraints dictated by the password policy, and the notification of the authentication results, which would result in taking the appropriate actions to update the password policy status information (grace login counts, and so). Note that, based on the different sequence of operations the authentication and authorization process would perform in case of success or failure, the DSA could likely infer the result without a direct notification from the auxprop plugin (this would be especially true for OpenLDAP's auxprop mech builtin in slapd); so the second step might not be required, but this could be very implementation dependent and not general enough. We didn't get so far with the discussion yet; it's not even clear enough yet how much an authentication process that is password based, with the password stored in LDAP, and thus falling into the scope of draft- behera-ldap-password-policy could actually be covered by the I.D. and what modifications this would require. It is not my intention to overload this message with implementation details, which shouldn't influence the draft beyond some common sense point; the point we would like to make is: would it make sense to extend the draft to include "search" operations in a manner similar to "compare"? In the scenario we envisage for password policy exploitation by password-based SASL mechanisms, a search request with base scope and with the password policy control that requests the pwdAttribute would qualify as an authentication attempt, and thus be subjected to password policy restrictions derived from those of the "compare" operation: o searchResponse.resultCode = insufficientAccessRights (50), passwordPolicyResponse.error = accountLocked (1): The password failure limit has been reached and the account is locked. The user needs to retry later or contact the password administrator to reset the password. o searchResEntry, passwordPolicyResponse.warning = graceAuthNsRemaining: The password has expired but there are remaining grace authentications. The user needs to change it. o searchResponse.resultCode = insufficientAccess (50), passwordPolicyResponse.error = passwordExpired (0): The password has expired and there are no more grace authentications. The user must contact the password administrator to reset the password. o searchResEntry, passwordPolicyResponse.warning = timeBeforeExpiration: The user's password will expire in n number of seconds. Note that the password policy response control would be attached to the searchResponse for those cases where the authentication must fail, while it would be attached to the searchResEntry for those cases where only a warning has to be issued. The DSA would treat a searchRequest of this kind as bind attempts, and, for those cases where the entry is successfully returned, treat them as failed binds, unless a subsequent operation notifies that the authentication was successful. This operation has yet to be discussed; I'm thinking about some kind of extended operation (e.g. with the DN of the entry as requestDN, and the authenticationResult as value) that administers the policy-related attributes (e.g., removes the last pwdGraceUseTime which was added by the previous successful searchRequest if the password was expired, and the pwdFailureTime that has to be added anyway). The removal of those attributes cannot be directly performed by the modify operation, as they are NO-USER-MODIFICATION; this would be the result of this special operation that resets the status of the entry in case of successful authentication. Kurt Zeilenga, of the OpenLDAP Project, believes that this issue falls beyond the scope of draft-behera-ldap-password-policy, as it affects application authentication. As such, he suggests that a separate specification is considered, where password policy state information held in a DSA could be updated by the application, including NO-USER- MODIFICATION, by way of the "manageDIT" control (no specification yet; experimental control implemented in OpenLDAP). My objection, in this case, is that there would be a lot of overlapping between those two specifications, and both the DSA and the authentication application would have to do mostly the same work. In the design I'm envisaging, on the contrary, the application would delegate the password policy enforcement to the DSA, by way of a two- stage interface: the search operation used to lookup the credentials, which would be treated by the DSA as a failed bind in terms of password policy semantics, and the authentication result notification, which would trigger the state information reset by DSA, without any specific knowledge, at the authentication application side, of the details of the state info. In this two-step scenario it appears that an opaque cookie should be used to relate the notification to the appropriate search. The cookie, in the simplest case, could contain the timestamp that is used in the pwdGraceUseTime and in the pwdFailureTime, possibly using the fractional seconds to ensure its unicity. This message should be considered a notification of the problem we're addressing; we're open to suggestions for different solutions. We think it would be important to include this further lookup-based mechanism into those accounted for by the LDAP password policy I.D., because it would broaden its application to authentication mechanisms that are closely related to those currently addressed. p. Ing. Pierangelo Masarati Responsabile Open Solution OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Dec 28 10:55:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErdeO-0003g6-IL; Wed, 28 Dec 2005 10:55:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErdeN-0003fx-6p for ldapext@megatron.ietf.org; Wed, 28 Dec 2005 10:55:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21308 for ; Wed, 28 Dec 2005 10:54:28 -0500 (EST) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErdiQ-0003sH-Pe for ldapext@ietf.org; Wed, 28 Dec 2005 10:59:51 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBSFtSGs027760 for ; Wed, 28 Dec 2005 10:55:29 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBSFtSAF103974 for ; Wed, 28 Dec 2005 10:55:29 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBSFtSkG018171 for ; Wed, 28 Dec 2005 10:55:28 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.229.77]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBSFtSDI018155 for ; Wed, 28 Dec 2005 10:55:28 -0500 In-Reply-To: <1135688297.3650.7.camel@ando> Subject: Re: [ldapext] Interaction of with authentication applications To: ldapext@ietf.org X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: John McMeeking Date: Wed, 28 Dec 2005 09:55:25 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 7.0|August 18, 2005) at 12/28/2005 09:55:27 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org >From a client pespective, what you describe sounds like internal details of the DSA implementation, thoughin this case, the DSA is a federation of a core server and third party components. I think the password policy drafts should be describing DSA behavior that is discernible to a client; so I believe this is outside the scope of the drafts. John McMeeking Pierangelo Masarati wrote on 12/27/2005 06:58:17 AM: > Dear all, > > Howard Chu and I, of the OpenLDAP Project, and Alexey Melnikov of Cyrus > SASL have been chatting about the issues of making password-based SASL > mechs aware and respectful of any Password Policy mechanism implemented > at the DSA that contains the passwords, and used by the SASL mechanisms > by way of auxprop lookup. I'll briefly summarize the private discussion > we had, and then expose my suggestions for a possible evolution of > draft-behera-ldap-password-policy. > > Auxprop lookup consists in looking up the credentials and performing the > authentication outside of the DSA. > > Currently, Cyrus SASL can lookup credentials from a DSA by performing a > WhoAmI extended operation to determine the DN of the entry corresponding > to a user, and then looking up the auxprops by a search with that DN as > base and a baseScope. All the operations are performed using an > administrative identity, which is supposed to have read access to the > auxprops, including the password. > > Password policy enforcement would need to be either essentially > delegated to the SASL auxprop, in a cooperative agreement with the DSA, > and giving up with respect to some features, or split in two phases, > again under some cooperative agreement between the DSA and the > application: the lookup of the password, which would be subjected to > constraints dictated by the password policy, and the notification of the > authentication results, which would result in taking the appropriate > actions to update the password policy status information (grace login > counts, and so). Note that, based on the different sequence of > operations the authentication and authorization process would perform in > case of success or failure, the DSA could likely infer the result > without a direct notification from the auxprop plugin (this would be > especially true for OpenLDAP's auxprop mech builtin in slapd); so the > second step might not be required, but this could be very implementation > dependent and not general enough. > > > > We didn't get so far with the discussion yet; it's not even clear enough > yet how much an authentication process that is password based, with the > password stored in LDAP, and thus falling into the scope of draft- > behera-ldap-password-policy could actually be covered by the I.D. > and what modifications this would require. > > It is not my intention to overload this message with implementation > details, which shouldn't influence the draft beyond some common sense > point; the point we would like to make is: would it make sense to extend > the draft to include "search" operations in a manner similar to > "compare"? In the scenario we envisage for password policy exploitation > by password-based SASL mechanisms, a search request with base scope and > with the password policy control that requests the pwdAttribute would > qualify as an authentication attempt, and thus be subjected to password > policy restrictions derived from those of the "compare" operation: > > o searchResponse.resultCode = insufficientAccessRights (50), > passwordPolicyResponse.error = accountLocked (1): The password > failure limit has been reached and the account is locked. The > user needs to retry later or contact the password administrator to > reset the password. > > o searchResEntry, > passwordPolicyResponse.warning = graceAuthNsRemaining: The > password has expired but there are remaining grace > authentications. The user needs to change it. > > o searchResponse.resultCode = insufficientAccess (50), > passwordPolicyResponse.error = passwordExpired (0): The password > has expired and there are no more grace authentications. The user > must contact the password administrator to reset the password. > > o searchResEntry, > passwordPolicyResponse.warning = timeBeforeExpiration: The user's > password will expire in n number of seconds. > > Note that the password policy response control would be attached to the > searchResponse for those cases where the authentication must fail, while > it would be attached to the searchResEntry for those cases where only a > warning has to be issued. > > The DSA would treat a searchRequest of this kind as bind attempts, and, > for those cases where the entry is successfully returned, treat them as > failed binds, unless a subsequent operation notifies that the > authentication was successful. This operation has yet to be discussed; > I'm thinking about some kind of extended operation (e.g. with the DN of > the entry as requestDN, and the authenticationResult as value) that > administers the policy-related attributes (e.g., removes the last > pwdGraceUseTime which was added by the previous successful searchRequest > if the password was expired, and the pwdFailureTime that has to be added > anyway). The removal of those attributes cannot be directly performed > by the modify operation, as they are NO-USER-MODIFICATION; this would be > the result of this special operation that resets the status of the entry > in case of successful authentication. > > > > Kurt Zeilenga, of the OpenLDAP Project, believes that this issue falls > beyond the scope of draft-behera-ldap-password-policy, as it affects > application authentication. As such, he suggests that a separate > specification is considered, where password policy state information > held in a DSA could be updated by the application, including NO-USER- > MODIFICATION, by way of the "manageDIT" control (no specification yet; > experimental control implemented in OpenLDAP). > > My objection, in this case, is that there would be a lot of overlapping > between those two specifications, and both the DSA and the > authentication application would have to do mostly the same work. In > the design I'm envisaging, on the contrary, the application would > delegate the password policy enforcement to the DSA, by way of a two- > stage interface: the search operation used to lookup the credentials, > which would be treated by the DSA as a failed bind in terms of password > policy semantics, and the authentication result notification, which > would trigger the state information reset by DSA, without any specific > knowledge, at the authentication application side, of the details of the > state info. In this two-step scenario it appears that an opaque cookie > should be used to relate the notification to the appropriate search. > The cookie, in the simplest case, could contain the timestamp that is > used in the pwdGraceUseTime and in the pwdFailureTime, possibly using > the fractional seconds to ensure its unicity. > > > > This message should be considered a notification of the problem we're > addressing; we're open to suggestions for different solutions. We think > it would be important to include this further lookup-based mechanism > into those accounted for by the LDAP password policy I.D., because it > would broaden its application to authentication mechanisms that are > closely related to those currently addressed. > > > > p. > > > > > > > > Ing. Pierangelo Masarati > > Responsabile Open Solution > > OpenLDAP Core Team > > > > SysNet s.n.c. > > Via Dossi, 8 - 27100 Pavia - ITALIA > > http://www.sys-net.it > > ------------------------------------------ > > Office: +39.02.23998309 > > Mobile: +39.333.4963172 > > Email: pierangelo.masarati@sys-net.it > > ------------------------------------------ > > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext