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

Re: [ldapext] Splitting Password Policy



I think I can do that.
 
For purposes of reuse, it will require that the protocol specification only give abstract descriptions as to the reasons why certain errors and warnings are to be returned, and the pwd policy doc (containing the data model) will prescribe specific behavior regarding the state data.
 
Jim

>>> Alexey Melnikov <Alexey.Melnikov@isode.com> 10/28/04 6:41:38 AM >>>
Kurt D. Zeilenga wrote:

>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.
>
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.

>
>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).
>>
>>
>>

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext