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

From: Pierangelo Masarati <[email-masked]>
Date: Tue, 27 Dec 2005 13:58:17 +0100

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:    [email-masked]

------------------------------------------

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: John McMeeking <[email-masked]>
Date: Wed, 28 Dec 2005 09:55:25 -0600

>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