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

  • From: Kurt Zeilenga <Kurt.Zeilenga@xxxxxxxxx>
  • To: simo <idra@xxxxxxxxx>
  • Date: Mon, 31 Mar 2008 16:13:23 -0700


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@xxxxxxxxx>
Senior Software Engineer at Red Hat Inc. <ssorce@xxxxxxxxxx>

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

-----
www.x500standard.com: The central source for information on the X.500 Directory 
Standard.

Other related posts: