Re: [ldapext] Interaction of <draft-behera-ldap-password-policy> with authentication applications

[John McMeeking <jmcmeek@us.ibm.com>]

>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