Re: comments on ldap password policy draft

[Jim Sermersheim <JIMSE@novell.com>]

Kurt.

>>	In this document, the
>>      term "user" represents any application which is an LDAP client
>>      using the directory to retrieve or store information.
>
>This terminology might be confusing when discussiong 3rd party
>authenication applications.  I suggest using user to refer to
>the entity being authenticated and client to refer LDAP
>application which is submitting LDAP requests on behalf of this
>entity.

Good idea.

>>
>>      ( pwdSchema.1.4
>>        NAME 'pwdCheckSyntax'
>>        DESC'a flag which indicates whether the password syntax will be
>>            checked before the password is saved'
>
>'Syntax' implies that this is enabling a schema check.  It's
>actually enables various checks for password restrictions.
>I would suggest renaming this attribute or, at least,
>changing this attribute's description.

Agreed.

>>      ( pwdSchema.1.5
>>        NAME 'pwdExpireWarning'
>>        DESC'the maximum number of seconds before a password is due to
>>            expire that a warning message is to the user. A value of 0
>>            means no warning will be sentÆ
>
>Sounds like the user is going to be sent an unsolicited notification
>message of some sort.

The only time the user will see a message is via a control on the bind response.

>>	( pwdSchema.1.11
>>	  NAME 'pwdDefaultStorageScheme'
>>        DESC'the type of hash algorithm used to store directory server
>>            passwords'
>
>used 'by default'.   That is, that scheme which is currently used
>for generation of hashed password values for storage purposes.
>Also, I would like to see an attribute which enumerates
>which hash algorithms are currently supported for checking passwords.
>Many servers can support checking against multiple hash algorithms
>([S]MD5, [S]SHA, crypt, etc.).  That is, you can change the policy
>for generation of passwords for storage purposes while to support
>checking against both new and old hash algorithms.

I agree we need to make the description more clear.  Your second point, asks for a new attribute which advertises the server's comparison/checking capabilities. Does this add value other than making a client aware of the possible storage schemes?  If not, I'd again like to see what comes of these two drafts in the works <crypt attribute subtype for userPassword> and <advertisement of attribute type options> before creating this new attribute.

>>      The description of password storage scheme can be found in [RFC-
>>      2307].
>
>It should be noted two storage schemes can be found in RFC-2307.
>Also note that RFC-2307 is has a few holes, such as it doesn't
>describe how the encryptedpassword should encoded to string.  I
>suggest that such details be left to implementations (and
>future drafts) and remove from this draft all dependency upon
>RFC-2307.

We could remove the reference and either refer to another standards track draft or simply enumerate valid values in this draft.

>>   4.4 Attribute types used by the pwdInfObject Object Class
>>
>>      ( pwdInfObject.1.1
>>        NAME 'pwdExpirationTime'
>>        DESC'the time the entry's password expires. A 0 means that the
>>            password has expired. If this attribute does not exist, the
>>            password will never expire'
>
>If an administrator changes expiration policy, each pwdExpirationTime
>in that policy would need to be adjusted.  If an administrator
>didn't previously have an expiration policy, it not possible to
>establish an pwdExpirationTime specific to this entry and as
>until the administrator does add some pwdExpirationTime value,
>the current password will never expirse.  If a password expiration
>policy is in affect, no pwdExpirationTime should imply 'has expired'.
>
>I would suggest that this attribute be replaced with an attribute
>which would serve as timestamp for each password modification.
>This would allow for a expiration policy change to made with
>requiring change to each entry under that policy.  The password
>of an entry without a such timestamp would be considerred expired
>if an expiration policy was in effect.

pwdExpirationTime, is essentially a future time to expire is calculated once and simply compared to the current time when checking for expiration.  Your suggestion would cause a calculation to happen each time a bind occurs. So I guess we need to decide which is the lesser of two evils, re-calculating expirations when the policy changes or the overhead of calculating at each bind. Thinking...

>>   5. Password Expiration and Expiration Warning
>>
>>      The attributes pwdMaxAge and pwdExpireWarning are defined to
>>      specify when the password expires and when a warning message will
>>      be sent to the client respectively.
>
>Again, sounds like the server should send an unsolicited notification
>of some sort...

Same as above, there's just a control on the bindRequest. We should clarify.

>>	The actual expiration time
>>      for a password will be stored in the pwdExpirationTime attribute
>>      of the user entry.
>
>As noted above, this requires each entry under the policy to be
>updated whenever the expiration policy changes.

Right.

>>   8. Password Syntax and Minimum length
>>      The pwdCheckSyntax attribute indicates whether the password
>>      syntax will be checked before a new password is saved.
>
>I suggest s/syntax/restrictions/.

Yes.

>>      If the client is sending an encrypted password as the new
>>      password then it becomes the client responsibility to make sure
>>      that the password meets the minimum length and other constraints.
>
>There should be a requirement that servers publish password
>policy to any client which can modify an attribute under the
>policy. (Much like the requirement to publish schema for any
>attribute that a client can modify).

This should be done through the RootDSE, Section 14 needs to address how the password policies are published and associated with specific entries. This issue is a hole we decided to deal with in the next rev.

>>   9. User Defined Passwords
>>
>>      This policy defines whether the users can change their own
>>      passwords.
>>      During modify password operation, the server should check if the
>>      user is allowed to change password. If not, the server should
>>      send to the client the LDAP_UNWILLING_TO_PERFORM result code and
>>      an error message to indicate that the user is not allowed to
>>      change the password. Note that the userPassword attribute may be
>>      protected via ACLs also and the user must have necessary
>>      privilege to modify the userPassword attribute values.
>
>Which checks, access policy or password policy, are applied first.
>That is, if a modify operation violates both policies, which error
>will be returned.  I would assume access controls would be applied
>first.

Right, we can clarify that.

>>      After that, for any operation issued by the user other than
>>      modify password, bind, unbind, or abandon the server should send
>>      the response message with the resultCode:
>>      LDAP_UNWILLING_TO_PERFORM, and should include the password
>>      expired control in the controls field of the response message:
>
>All this special unwillingToPerform behavior gives me the willies.

In this case at least, the unwillingToPerform result is accompanied by a control that tells the client what's going on.

>>
>>      In ldif format:
>
>Nit: No DN, not valid LDIF (no DN).  And 'LDIF format' is redundant.
>And a reference, please.

Thanks.

>>         pwdStorageScheme: SHA
>
>Should be pwdDefaultStorageScheme.

Right.

>More later...

Thanks Kurt.