[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
[ldapext] Interaction of <draft-behera-ldap-password-policy> with authentication applications
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