[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] 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" <Kurt@OpenLDAP.org> 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
>_ Ldapext@ietf.org <mailto:Ldapext@ietf.org>_
>_ https://www1.ietf.org/mailman/listinfo/ldapext_


------------------------------------------------------------------------

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
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/
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext