Re: Splitting Password Policy

Hm, just tripped over this again in my Inbox. Was there any progress on this 
work? I've just now finished reformatting draft-behera-...-09 into XML and 
updating it to reference RFC4511-4517, in preparation for making further 
additions. But if there's already been work done on splitting the document, 
I'd rather continue from there.

IMO, we really do need a spec for "Login Policy" not just password policy, and 
we need to expose it such that other mechanisms (e.g. Kerberos, SASL) can 
utilize it consistently with simple requests (i.e., without having to 
reimplement the guts of the policy themselves). Likewise, in my edit of 
RFC2307 I am recommending that LDAP password policy be used instead of the 
shadowAccount schema for login authorization.

Jim Sermersheim wrote:
> After talking this over, we've decided to try both. In other words,
> splitting the document into four different drafts like this:
> 1) LDAP authentication control for password policy
> 2) LDAP update control for password policy
> 3) LDAP password-based authentication policy
> 4) LDAP password update policy
> #1 and #2 will essentially define the protocol elements and the
> various policy decisions to be made.
> #3 and #4 will define the schema elements and how to use them to
> implement the policy decisions defined in #1 and #2.
> We can probably find better names than the ones I've jotted down here.
>
> >>> "Kurt D. Zeilenga" <[email protected]> 10/26/04 6:21:25 PM >>>
> 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
> >_______________________________________________
> >Ldapext mailing list
> >_ [email protected] <mailto:[email protected]>_
> >_ https://www1.ietf.org/mailman/listinfo/ldapext_
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ldapext mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ldapext


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/