Subject: [ldapext] Splitting Password Policy

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 26 Oct 2004 10:00:50 -0600

All,
 
Speaking on behalf of some people on the CC list, it is seen as
desirable to place password update policy in one specification, and
place password use policy in another specification.
 
This started as an act of associating password use policy (such as
intruder detection policy) with login policy (such as allowable login
times, addresses, etc).
 
It then diverged from that and ended up being described as: Password
policy is policy that applies only to simple bind passwords. Login
policy involves policy that can be applied to *any* kind of
credentials.
 
My argument was that policy like password expiration (while enforced at
authN time) is intimately tied to password updates. Thus, if we were to
split this into two I-Ds, there would be some amount of cross
referencing, and cross requirements (password expiration would require
actions during password update).
 
I know some people in the community have asked for more "login policy"
type things to be added to the I-D, and we've pushed against adding
those.
 
What are other's feelings in this area? (Tammy, Duane, Hal, feel free
to clarify these positions).
 
Jim

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 26 Oct 2004 09:21:25 -0700

Just a thought, but it might also be useful to split the
protocol elements from the schema elements.  The protocol
controls could be genericized to support expiration of
other kinds of credentials.

At 09:00 AM 10/26/2004, Jim Sermersheim wrote:
>All,
> 
>Speaking on behalf of some people on the CC list, it is seen as desirable to place password update policy in one specification, and place password use policy in another specification.
> 
>This started as an act of associating password use policy (such as intruder detection policy) with login policy (such as allowable login times, addresses, etc).
> 
>It then diverged from that and ended up being described as: Password policy is policy that applies only to simple bind passwords. Login policy involves policy that can be applied to *any* kind of credentials.
> 
>My argument was that policy like password expiration (while enforced at authN time) is intimately tied to password updates. Thus, if we were to split this into two I-Ds, there would be some amount of cross referencing, and cross requirements (password expiration would require actions during password update).
> 
>I know some people in the community have asked for more "login policy" type things to be added to the I-D, and we've pushed against adding those.
> 
>What are other's feelings in this area? (Tammy, Duane, Hal, feel free to clarify these positions).
> 
>Jim

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 28 Oct 2004 13:41:38 +0100

>other kinds of credentials.
I agree.
And the password policy control can be used with other password policies 
(e.g. NIS schema).
So yes, I am in favor of splitting the control and other protocol bits 
into a separate document.