Re: [ldapext] Fwd: I-D Action:draft-zeilenga-ldap-passwords-00.txt

[Kurt Zeilenga <Kurt.Zeilenga@Isode.com>]

On Mar 31, 2008, at 2:07 PM, simo wrote:
>
> On Mon, 2008-03-31 at 10:56 -0700, Kurt Zeilenga wrote:
>>> A URL for this Internet-Draft is:
>>>
>> http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-passwords-00.txt
>
> Some comments on the draft:
>
> 1)
>
> In the document I see 'pwd' in a former incarnation has been  
> replaced by
> 'passwd', why not the full 'password' ?

No particular reason.

>
>
>
> 2)
>
>> 3.1.3. 'passwdExpiry'
>>
>>  The 'passwdExpiry' attribute specifies the age, in seconds, in  
>> which a
>>  password expires.
>
> This is the number of seconds since the password is changed, right ?

Yes.

> This is in the policy itself, and means all password for users in the
> same subtree expire 'passwdExpiry' seconds after their password change
> date as recorded by: 'passwdChangeTime'

Yes.

> It is not allowed to have a different expiration time unless a  
> specific
> policy is created for the user(s).

Yes.

> With the proposed draft a change in the policy may suddenly expire a
> great number of passwords unexpectedly (example: I am changing the
> default policy from 90 days to 30 days expiration time).

This is the intended behavior.

> Another way to handle this is to have passwordExipryTime on the user
> entry that express the expiration as generalized time.  
> 'passwdExpiry' in
> this case is used at password change time to determine the value of
> passwordExipryTime at the time of the change.


> This means that followinf changes to the policies do not change the
> recorded expiration date for password changes made in the past.

Which some may find this to be unexpected behavior.

> What is the reason for the proposed approach is preferred to this
> alternative one ? (I am assuming both have been considered)

I believe that when the expiration policy is changed from N to M days,  
the policy administrator expects that policy to be applied to all  
passwords, not just those set after the policy change.

> 3)
>
> 4.2. Minimum Length
>
>  The Minimum Length constraint restricts the length of allowed
>  passwords, requiring all passwords to have at least the number of
>  octets specified in the parameter.  [...]
>
> Here minimum length is expressed in octects, but in UTF-8 multiple
> octects can encode for a single character. And therefore a password  
> can
> be 'shorter' is simply octect are counted.
>
>
> Shouldn't the minimum length indicate the minimum number of  
> characters ?

A password doesn't necessarily consist of character data, so specify  
their length in characters doesn't make any sense.

> 4)
>
> The number of constraints seem quite limited, are you open to  
> suggestion
> for more constraint types that are currently commonly used in various
> server implementations ?

Yes.

>
>
>
>
> Simo.
>
> -- 
> Simo Sorce
> Samba Team GPL Compliance Officer <simo@samba.org>
> Senior Software Engineer at Red Hat Inc. <ssorce@redhat.com>
>
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www.ietf.org/mailman/listinfo/ldapext

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