[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] 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/
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext