Subject: Re: [ldapext] Unfinished business: password policy and VLV

From: Howard Chu <[email-masked]>
Date: Fri, 03 Jul 2009 20:02:17 -0700

John McGarvey wrote:
>
> Kurt,
>
> It seems questionable to introduce a new password policy approach when
> many existing servers implement a form of the Behera draft. I suspect
> that the result would not be widely implemented.

And another year goes by... I have to agree. Whatever problems exist with the 
Behera draft should be fixed, rather than launching another completely 
different proposal.

Going thru Appendix A of 
http://tools.ietf.org/html/draft-zeilenga-ldap-passwords-00

re: the "guessing limit" - as braindead as this feature may be, many sites are 
required to support it due to Sarbanes-Oxley or various other government 
regulations. I think the best thing to do here is note that it is 
bass-ackwards from a security point of view, but because ignorant policy 
makers require it, it is included in the spec. I.e., provide the feature but 
fully document why it's a bad feature and provide alternatives to use in its 
place.

re: lockout - it may be beyond the scope of "password policy" management but 
the solution is needed. In the absence of any additional work occurring in 
this area in a year and a half, it seems best to simply expand the scope of 
this spec - to include rudimentary account management - and define formal 
mechanisms for account expiration and disablement.

re: grace logins - time-limited is certainly more sensible.

re: disallowing user password changes - ok.

re: protocol extension - that section appears to be missing from the draft. 
While providing this info at other times may be useful, the most common case 
for users to interact with the password policy machinery is at login time, so 
it's not clear what other cases you wanted to allow for. If I successfully 
change my password and get a reply "by the way - your password will expire in 
90 days" I will promptly forget it, nor do I actually need to spend any time 
thinking about it until shortly before it expires again.

re: bind and compare - ok, certainly we should discourage use of Compare as an 
authentication method.

re: DSA-generated passwords - ok, let's add this to Behera.

re: password min length and max length - ok.

re: password history - ok, time-based is better.

re: password history storage - it may be a local matter, but I think we should 
still provide an Informational definition here, because leaving it up to each 
individual site to implement will cause too much wheel-reinvention and will 
harm interoperability.

At this point we have several years worth of accumulated experience with 
deployments of the Behera draft. We shouldn't throw that away. Most of the 
issues you address can be fixed as an incremental revision of Behera.

Requests for an absolute expiration/lockout mechanism keep coming up time and 
again. It's too small a feature to merit its own document. We should simply 
add a couple new attributes to the existing Policy schema and be done with it.

Another item that has come up from my perusal of Kerberos KDC policy - in 
addition to specifying a time when a password stops being valid, it would be 
nice to provide an attribute specifying the time when a password *starts* 
being valid.

For password constraints, a regexp constraint would definitely be useful.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

---

From: Kurt Zeilenga <[email-masked]>
Date: Sat, 4 Jul 2009 06:59:54 -0700

Howard,

I note that the ITU/ISO has been working on a X.500 Password Policy  
mechanism, see <http://www.x500standard.com/index.php? 
n=Ig.Extension>.  I would argue that if the IETF is to do anything in  
the area of password policy standardization, it should consider simply  
adapting the X.500 mechanism for use in LDAP.

I encourage those who have issue with the ITU/ISO proposal to comment  
on the X.500 mailing list, see <http://www.x500standard.com/index.php?n=Participate.MailingList 
 >.

-- Kurt

---

From: Howard Chu <[email-masked]>
Date: Mon, 06 Jul 2009 17:35:55 -0700

Kurt Zeilenga wrote:
> mechanism, see<http://www.x500standard.com/index.php?
> on the X.500 mailing list, see<http://www.x500standard.com/index.php?n=Participate.MailingList
>   >.

I've sent an initial set of comments to the X.500 list. It seems that a number 
of the concerns you raised with the Behera spec are already addressed in their 
current draft. E.g., they at least mention the DOS problems with failure-based 
lockouts, providing policy state attributes for delaying instead of plain 
lockouts.

The X.500 draft also supports time-based password history limiting and grace 
logins, which looks good. It has some obvious flaws too, such as storing the 
pwdExpirationDate instead of just computing it from pwdChangedTime and 
pwdExpireAge.

In the meantime, whether we discuss this in the X.500 context or here, I'd 
like to add these features in addition to what has already been discussed:
    a) pwdStartDate - when the credential becomes valid
    b) pwdLastSuccess - date of the last successful authentication
    c) pwdMaxIdle - interval after which account is locked if no successful 
auth occurs

And also an extended op "ExternalBind" for allowing external authentication 
providers to interact with the existing policy. I.e., this op will supply an 
LDAP username and a success/fail code to the directory server, and the server 
will execute the policy mechanisms accordingly. (E.g., if a Fail code is 
supplied then the failure time and any relevant lockouts are recorded.)