Subject: Re: ldap password policy approach

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 22 Oct 1999 14:20:59 -0600

>>> "Kurt D. Zeilenga" <[email-masked]> 10/22/99 1:22:33 PM >>>
>As I've was rereading this draft, a few things struck me as
>being overly complex.  Most of this complexity is caused
>by enforcing policy when modify used to set credentials.
>
>An alternative approach would be use a control sent with a
>BindRequest to specify new credentials.  Here is a little
>food for thought.

Kurt, I think we should try to use existing LDAP functionality where it makes sense, and only turn to controls/extensions when that fails or becomes a poor fit.

That said, I think using LDAP modify to modify your password is not so much of a leap that it's confusing or poor design, perhaps there are some things that the draft spells out which could be made less complex, I'd rather look at reducing complexity that way than proliferating  controls/extensions.

<snip>

>Additionally, a control (enforcePasswordPolicy) could be
>defined, and specified with operations that modify the stored
>credentials, that would enable password policy processing.
>A well behaving 3rd party authentication application would
>provide an enforcePasswordPolicy critical control.

I'd really like to keep the onus of password policy enforcement on the server.  If clients can dictate when and how to enforce security related policies, how does an administrator ensure security? Who polices all the 3rd party authentication applications to make sure they're well behaved?

I'd really like to talk in specifics about where the complexities that you've observed lie, and try to address them.

Jim

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 23 Oct 1999 10:38:06 -0700

At 02:20 PM 10/22/99 -0600, Jim Sermersheim wrote:
>That said, I think using LDAP modify to modify your password is not so much of a leap that it's confusing or poor design

The first problem with using modify to modify your password is that it
assumes that the password is stored in a user modifiable attribute.
RFC2251 allows a server to use other means.  If your approach were
to become required, it would remove this flexibility.

The second problem is that approach requires broad modifications
to server implementions.  The behavior of most every operation
has to be changed.  The behavior is dependent upon additional
per-session state information.  Efficient implementation
of your approach may require significant server redesign.

The third problem is that the approach requires the server to
examine each and every add,modify,(delete?),and compare to
determine if it acts upon the password attribute such
that it can execute appropriate codes.   The increases the
general overhead of these operations.

The approach also disallows operations which must be allowed
(per RFC2251).  The client may, at times, be only be allowed
to modify the password attribute.  However, the client must
be allowed to examine of schema rules for that attribute.
The client should also be allowed to example the password
policy and RootDSE.  Though this can be resolved by special
case processing... it just adds more complexity.

It also appears that the approach appears to disallow
access to the stored value, requiring clients to provide
the password instead of the encoding of the hash of the
password.   There are numerous applications which require
such access (administrative purposes, replication, etc.).

The approach requires significant modification to applications
desiring to interact with the password policy system.  Existing
clients might get quite confused in some situations offerred
by the approach.

I am also concerned that this approach might have hidden
synchronization requirements placed upon servers to enforce
this policy in face of concurrent operations posted by the
client.

> Who polices all the 3rd party authentication applications to
> make sure they're well behaved?

The administrator.  No approach which can stop a 3rd party
authentication application from circumventing the password
policy.  It's up to the administrator to choose well behaved
applications (and to define "well behaved").

----
Kurt D. Zeilenga		<[email-masked]>
Net Boolean Incorporated	<http://www.boolean.net/>