Subject: Re: ldap password policy approach

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 27 Oct 1999 20:12:54 -0600

Thanks Kurt.

After mulling this over, I see two general directions we can take this draft. We could attempt to solve the problems you bring up by applying one of these solutions: Define a new operational attribute which is used to modify passwords (via LDAP modify), or define a bind control (as you suggested) or an extension which would isolate the mechanism from the modify code. In either case, the server implementation would be free to store the user password in whatever attribute/format it chooses. Each solution has its pros and cons.

The other direction is to divorce the password policy document from the mechanisms used to change passwords.  In other words, the policy document would only present policy which is used when performing certain password related operations, not dictate how one goes about performing those operations. In this case, I would expect to see language like, "The LDAP modify operation MAY be used on the userPassword attribute, or another mechanism MAY be used to change the password". A future document could address the issue of standardizing the operation used to perform password modifications.

I'm leaning towards the second approach because it leaves the policy document in a cleaner state.  One issue I see is the prescribed format of the pwdHistory attribute.

What do you think?

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 10/23/99 11:38:06 AM >>>
At 02:20 PM 10/22/99 -0600, Jim Sermersheim wrote:
>>>> "Kurt D. Zeilenga" <[email-masked]> 10/22/99 1:22:33 PM >>>
>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.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 27 Oct 1999 19:44:28 -0700

>What do you think?

I concur that the password policy should be divorced from the
password storage.  It's my view that, like RFC2251, the password
policy should not place any restrictions upon how servers store
credentials.

As far as the pwdHistory attribute type, I would suggest avoid
defining it.  That is, the policy needed concern it self with
how a server records the history to enforce the policy.  It
just needs to enforce the policy.

Kurt

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 28 Oct 1999 10:54:33 -0700

At 07:25 PM 10/28/99 +0200, Ludovic Poitou wrote:
>By not describing the pwdHistory attribute type, we will hit some
>interoperability problems with heterogeneous replicated environment
>(multi-master replication with different vendors servers).
>The pwdHistory attribute needs to be replicated and all servers need to
>know how to check a password against the history. Therefore, we need to
>specify how it looks like.

As we divorce the issue of password policy and storage, I believe
we'll find that how to store history of passwords should be
discussed as a storage issue, not a policy issue.

	Kurt

----

---

From: Ludovic Poitou <[email-masked]>
Date: Thu, 28 Oct 1999 19:25:03 +0200

Prasanta Behera wrote:

> "Kurt D. Zeilenga" wrote:
>
> Agreed.  The policy should say if "pwdHistory"  in on or off to
> tell the server to keep a history or not.

This is the pwdKeepHistory in the pwdPolicy object.

Ludovic.

> /prasanta

--
Ludovic Poitou
Sun Microsystems Inc.
Sun-Netscape Alliance - Directory Group - Grenoble - France

---

From: [email-masked] (Prasanta Behera)
Date: Thu, 28 Oct 1999 10:03:45 -0700

/prasanta