[x500standard] Re: New draft on password policy

  • From: Howard Chu <hyc@xxxxxxxxxxxxxxx>
  • To: x500standard@xxxxxxxxxxxxx
  • Date: Sun, 05 Jul 2009 18:26:54 -0700

Erik Andersen wrote:
Hi Folks,

SC6 has made the latest draft of Password Policy available. It may be
downloaded from http://www.x500standard.com/index.php?n=Ig.Extension.

SC6 has authorised that we bring this document forward to PDAM status
during the September 2009 meeting.

Please provide comments in time for that meeting.

Based on experience implementing various revisions of the LDAP Password Policy Draft

http://tools.ietf.org/draft/draft-behera-ldap-password-policy/

and concerns raised in Kurt's newer draft

http://tools.ietf.org/html/draft-zeilenga-ldap-passwords-00

I have several concerns, some related to keeping this X.500 draft cross-compatible with LDAP, and some related to password policy management in general.

1) relying on clients to know that they should be using an encrypted password, and to know which algorithm to use, seems impractical in the real world. IMO whether and how the password is encrypted should be a matter private to the DSA. a) the use of separate pwdHistory and encPwdHistory attributes is redundant; there should probably just be a single attribute whose values are tagged with their encryption method. One method should be reserved to mean "cleartext" i.e. unencrypted.
  b) the same consideration applies to userPwd vs encUserPwd.
c) clients should always supply plaintext, the DSA should perform any encryption as needed to validate the credentials.


2) Change of Password, section 8.3:
a) There doesn't seem to be any provision for an administrator to change another user's password. I.e., 8.3.2 requires the oldPwd to always be supplied. But the most frequent use case in the real world is for users who have forgotten their password, and need an administrator to reset it for them. As such, it must be valid within the definition of this operation to execute it without supplying the oldPwd, and other policy settings should determine when or for whom oldPwd is or is not required. b) It seems redundant to have a specific policy item and error code for "passwordModNotAllowed." Why aren't regular access control mechanisms already sufficient for this case? c) noPasswordSlot error - this appears to be an open invitation to Denial-of-Service. What if the last password was known to be stolen and needs to be changed immediately?

3) Password Policy, section 18.1.3:
a) Maintaining a pwdExpiryDate attribute is redundant information and imposes undue overhead. E.g., when the pwdExpiryAge is changed, the pwdExpiryDate for every affected entry must be recomputed and rewritten into the directory. It's best not to store this attribute at all, and always compute its value on the fly as needed.
  b) pwdEndDate is shown as pwdEndTime in Figure 10 and 11.
c) Allowing pwdEndDate to either be manually set or automatically computed from pwdMaxAge is error-prone. If pwdMaxAge is changed, should all pwdEndDates be recomputed as well? IMO the answer is No; as an admin I create accounts with a specific termination date and subsequent policy changes should not alter that date. IMO pwdMaxAge is ambiguous at best and unsafe at worst. d) expPwdCreationTime is redundant, it is obviously the same time as pwdCreationTime.

Section 18.1.5:
a) the name "pwdChangedTime" seems more intuitive than "pwdCreationTime" - any rationale behind this particular choice? Clearly it is set both at initial creation and at all subsequent updates. b) remAuthAttempts is ambiguous and discards information. For example, if pwdGraces is changed, the true number of grace logins that have occurred is lost. There should be a gracesUsed attribute instead of remAuthAttempts.

Section 18.1.6:
a) why is pwdQualityRule single-valued? Without an initial set of rules to serve as examples, it's difficult to evaluate the usefulness of this attribute. I would expect that multiple orthogonal rules will be defined and that a policy would allow combinations of these rules to be chosen. IMO this attribute should be multi-valued and at least one or two prototypical rules need to be part of the spec. As an example, a rule that validates the plaintext of a password against a regular expression would be useful.

Annex L:
Presumably all of the "encryption" algorithms available here are intended to be non-reversible, since there is no provision anywhere for storing an encryption key. In this case it would be more understandable to refer to these as "hashed" passwords, not encrypted.

Other:

One feature that both X.509 certificates and Kerberos tickets provide, that is missing in this and the LDAP specs, is a pwdStartDate parameter. There are expiration attributes to control when a credential stops being valid, but no corresponding parameter to control when it starts being valid.

In addition to allowing credentials to be disabled due to failed authentications, and due to passing a fixed expiration date, administrators frequently request a generic "disabled" boolean flag, for miscellaneous non-time-related reasons.

As noted in Kurt Zeilenga's draft, users are frequently poor at choosing passwords. It would be helpful to add a provision for DSA-generated passwords as a standard feature. E.g., there are a number of publicly available algorithms for generating "pronounceable" random passwords any of which are superior to the strings users are likely to invent on their own.

In discussions regarding how to leverage LDAP password policy for use by SASL and Kerberos KDCs a number of issues were pointed out. Basically, in order for external authentication providers to benefit from LDAP password policy, they must actually perform an LDAP Bind operation first. For most of these strong authentication mechanisms this is impractical since a plaintext password is required but is not available.

It was suggested that we define a new extended operation, "ExternalBind" which simply provides a user name and a success/fail status. The DSA would then execute the password policy machinery accordingly and return any relevant status codes. Given that one of the goals of the LDAP Password Policy initiative was to define policies that may be useful to other security mechanisms, I believe this new ExternalBind operation should also be an integral part of the Password Policy specification.

I think that covers my list of issues for now.
--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/
-----
www.x500standard.com: The central source for information on the X.500 Directory 
Standard.

Other related posts: