Re: Unfinished business: password policy and VLV

Kurt Zeilenga wrote:
>
> On Aug 5, 2009, at 4:15 AM, Howard Chu wrote:
>> Thinking about this some more, I don't think a new exop is the right
>> approach. Instead, I would use a new ppolicy control which can be
>> attached to a Search request.

> I suggest that such new protocol mechanisms, whether they be exop
> based or control based, be specified separately from the Password
> Policy document.  While they may be related, it would seem reasonable
> that an implementation might one to implement one but not the other.
> Modularization is a good thing.  Here I think it will aide in getting
> security right.

> Looking forward to discussing the devils in your details (I-Ds)...

After further thought, I didn't add anything on this front at all.

I've submitted a new draft, the announcement should be going out soon.

https://datatracker.ietf.org/idst/status.cgi?passed_filename=draft-behera-ldap-password-policy

Summarizing the differences from version 09:

1) changed explicit reference to user lockout in the Abstract to "deter 
password guessing attacks".

In general, we want to deprecate explicit lockouts and encourage other 
mechanisms, to avoid DoS.

2) Updated various references: RFC2251 -> RFC4511, RFC222 -> RFC4422, etc.

3) New section 4.1.1 (perhaps I should have appended instead of inserting and 
causing the others to be renumbered. Oh well.) "Password Validity Policy" 
describes mechanisms for enabling/disabling an account based on absolute start 
time, end time, and idle time since last successful login. This also provides 
a more straightforward means of locking out an account without overloading the 
pwdAccountLockedTime attribute.

4) Added delays for failed authentication to "Password Guessing Limit" section 
(now 4.1.2, was 4.1.1).

5) In 5.1, added pwdMaxLength, pwdGraceExpiry, pwdMinDelay, pwdMaxDelay,
and pwdMaxIdle policy attributes. Their full descriptions are in subsequent 
sections.

6) In 5.3, added pwdStartTime, pwdEndTime, pwdLastSuccess state attributes.

7) tweaked the comments for the pwdHistory syntax; couldn't use xref inside a 
<artwork> block so moved the references out of the comments.

8) In 7.1 added new lockout conditions based on pwdStartTime, pwdEndTime, and 
pwdMaxIdle + pwdLastSuccess.

9) In 7.4 (oops. forgot to take pwdGraceExpiry into account on this edit.)

10) In 7.6, renamed section from "Intruder Detection Check" to "Intruder 
Lockout Check", added new section "Intruder Delay Check".

11) In Password Too Young Check (now 7.8, was 7.7) added exception to allow 
changing password if the Must Change check returned true.

12) In 8., note that if a single password value is stored in multiple formats 
simultaneously, it still counts as just a single password value. It's common 
when centralizing multiple systems (SASL, Samba, Kerberos, NSS) into LDAP to 
need to have the password in multiple forms. They are all equivalent and are 
always changed simultaneously, so they are effectively only one password.

13) In 8.1.2.1 update the pwdLastSuccess attribute on successful 
authentication. In actual implementations I would make this optional, based on 
whether the pwdMaxIdle policy is configured or not.

14) Fixed a format/indent error, 8.1.2.5 and following are now 8.1.3

15) 8.1.2.5.2 "Lock on intruder detection" is now 8.1.3.2 "Handle Intruder 
Detection" where Lock is only one of the possible actions, Delay is the other 
possibility.

16) 9.5 Other Operations - also allow accountLocked result. This allows 
Search+ppolicy control to be used by SASL etc., instead of the ExternalBind 
stuff I mentioned in previous emails.

17) In 10. Administration, note that only one policy may be in effect for an 
attribute of an entry. If multiple policies overlap, the behavior is undefined.

18) In 11. Replication, replace "MUST be replicated" with "SHOULD be 
replicated", noting there are situations where replication of certain policy 
state attributes is not desired.

19) Author's Addresses - I know this is messed up; Jim Sermersheim is no 
longer at Novell, and I probably screwed up the format of Ludovic's address.

Things I didn't fix in this revision:

There are still several TODO sections from 09 which I didn't touch.

We've talked about more explicit pwdQualityRules, I haven't added any 
definitions for that yet.


Responses to draft-zeilenga-ldap-passwords Appendix A:

intruder detection check: added language to discourage use of this feature, 
added login delay policy.

pwdAccountLock overloading: added other mechanisms for explicit lockout.

pwdGrace use: I added pwdGraceExpiry to the policy, but forgot to incorporate 
it in the grace check section. Will add that shortly.

pwdAllowUserChange: I left this alone; we've already got it and it doesn't 
seem worth the trouble to delete it. The language already indicates it's only 
needed if the server doesn't already support access control, so in all 
likelihood it will never be used. If nobody speaks up and says "we can't live 
without this" I guess we can drop it from the next revision.

protocol extensions: Basically left this alone.

application to other operations: Basically left this alone. It's useful for 
external authentication mechanisms to interact with the policy.

require DSA-generated passwords: I didn't add this on this revision. Probably 
should add it on the next edit.

pwdMaxLength: added.

pwdHistory: I didn't add the time-based restriction. I think fixing the 
password-too-young check addresses the main problem, and I think that only 
using a time-based restriction may allow the history to grow without bound.

pwdHistory storage: I'm neutral on this; we already have it and it doesn't 
seem to be doing any harm, so again, more trouble than it's worth to delete 
it. I agree that it's DSA-specific, but the current definition works and it's 
likely that any DSA-specific implementation is going to look much like this 
anyway.

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