comments on ldap password policy draft

["Kurt D. Zeilenga" <kurt@openldap.org>]

At 02:16 PM 10/19/99 -0700, Prasanta Behera wrote:
>      The password policy defined in this document is applied to the
>      userPassword attribute values only in case of the LDAP simple
>      authentication method [RFC-2251]

RFC2251 doesn't meantion userPassword in the context of
authentication, neither should this document.  (See other thread)

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

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

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

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

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

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

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

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

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

>      LDAP_CONSTRAINT_VIOLATION

I am not sure constraintViolation is the most appropriate
resultCode to use.  I'll have to chew on this before making
any suggestions.

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

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


>      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 ldif format:

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


>         pwdStorageScheme: SHA

Should be pwdDefaultStorageScheme.


More later...

----
Kurt D. Zeilenga <Kurt@OpenLDAP.org>
OpenLDAP Project <http://www.OpenLDAP.org/>