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

From: Howard Chu <[email-masked]>
Date: Wed, 05 Aug 2009 04:15:41 -0700

Howard Chu wrote:
> 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.)

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. It would only be valid for searches of Base scope. It would result in 
a ppolicy response control being attached to the search entry that fulfills 
the search request. This would allow an external authentication mechanism to 
discover if the account is already locked, password is expired, etc. The 
response control would also include an opaque cookie.

We would also define a new ppolicy control which can be attached to a Simple 
Bind request. This control would carry the cookie from the previous response 
control, and a boolean success/fail value. If the cookie is valid, the 
credentials of the Bind request will be ignored and the boolean success/fail 
code is used to update the ppolicy state for the specified user.

At this point I'm preparing a new draft of the behera-ppolicy document with 
the several additions I've mentioned. I am also preparing a new revision of 
the RFC2307 schema, and a draft of a Kerberos 5 schema. Both of these latter 
documents will depend on the ppolicy draft. I plan to post these in the next 
couple of days.

-- 
   -- 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: Thu, 6 Aug 2009 09:27:44 -0700

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

-- Kurt

---

From: Howard Chu <[email-masked]>
Date: Sun, 09 Aug 2009 01:04:14 -0700

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

---

From: Howard Chu <[email-masked]>
Date: Mon, 10 Aug 2009 20:19:34 -0700

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

Fixed, will be in next draft.

> always changed simultaneously, so they are effectively only one password.

Equivalent text probably belongs in 4.3.

> stuff I mentioned in previous emails.

This appears to be a mistake, I'm reverting this to the 09 version.

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

TODOs:
   do we need to have configurable backoff algorithms for login delays? seems 
like overkill.

   password safe modification, intruder detection - one possibility is to 
force the session to immediately terminate on failure. That then accomplishes 
the aim of requiring users to authenticate first.

   pwdCheckQuality, checking during authentication. Sounds like a good idea; 
should it be done always, only when the stored password is hashed, or as a 
configurable choice? The result should be that pwdReset is effectively set 
when the verification succeeds.

   advertisement and discovery - the control should be advertised in 
supportedControls in the rootDSE, what else needs to be said?

   administrativeRole - will use another OID under the current arc.

   ppolicy and replication - I think there are enough caveats in here now.

   IANA considerations - I've filled these in according to RFC4520.

---

From: Jim Willeke <[email-masked]>
Date: Tue, 11 Aug 2009 05:34:45 -0400

pwdCheckQuality Enforcement, I think, must be a choice on Auth and on all
operations.

There are conditions where this could force everyone who authenticates to
change their password in a single day. With 1,000's or 1,000,000's of users,
an organization would be overwhelmed.

Some conditions I could think of are:
- Change to the password policy
- Transitioning to a new LDAP server or version. Where the "old" LDAP server
did not use the or enforce the password policy.
- Synchronization engines used to sync a password from a system whith a
weaker policy to a system with a stronger policy. It sometimes difficult to
match password policys between different vendors/versions of LDAP servers.

-jim
Jim Willeke

On Mon, Aug 10, 2009 at 11:19 PM, Howard Chu <[email-masked]> wrote:

> force the session to immediately terminate on failure. That then
> accomplishes the aim of requiring users to authenticate first.
>
> _______________________________________________
> Ldapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ldapext
>

---

From: Michael Ströder <[email-masked]>
Date: Fri, 14 Aug 2009 18:57:14 +0200

Howard Chu wrote:
> Howard Chu wrote:
>> 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.)
> 
> attached to a Search request. It would only be valid for searches of
> Base scope. It would result in a ppolicy response control being attached
> to the search entry that fulfills the search request. This would allow
> an external authentication mechanism to discover if the account is
> already locked, password is expired, etc. The response control would
> also include an opaque cookie.

Thinking in this direction a bit further I wonder how requests with Proxy
Authz control attached should be handled in case of (temporarily) locked accounts.

> We would also define a new ppolicy control which can be attached to a
> Simple Bind request. This control would carry the cookie from the
> previous response control, and a boolean success/fail value. If the
> cookie is valid, the credentials of the Bind request will be ignored and
> the boolean success/fail code is used to update the ppolicy state for
> the specified user.

What's the use-case for that?

> At this point I'm preparing a new draft of the behera-ppolicy document
> with the several additions I've mentioned. I am also preparing a new
> revision of the RFC2307 schema, and a draft of a Kerberos 5 schema. Both
> of these latter documents will depend on the ppolicy draft. I plan to
> post these in the next couple of days.

This all sounds very reasonable.

Ciao, Michael.

---

From: Howard Chu <[email-masked]>
Date: Fri, 14 Aug 2009 14:28:38 -0700

> What's the use-case for that?

I have already dropped this line of thought, so it's a moot point now.

I was thinking of SASL, Kerberos, and Samba ("external authentication 
agents"), which each can use LDAP as an authentication store, but perform the 
actual credential verification themselves. I wanted the ppolicy control 
attached to the Search request, to indicate that an authentication was being 
started. And I wanted the control to be attached to a Bind request, to allow 
the external agent to tell LDAP what the outcome of the authentication attempt 
was. This way the directory server can continue to maintain all the policy 
state thru the Bind mechanism. The external agent cannot simply issue an LDAP 
Simple Bind because they won't have the plaintext credentials on hand. I 
wanted a cookie in the control to authenticate that this Bind was a legitimate 
followon to the earlier Search, to prevent arbitrary clients from sending 
bogus "Bind/Failed" requests to the directory and thus effortlessly locking 
out any user of their choice.

But the existing ppolicy spec already allows external authentication, by 
virtue of the Compare request. After an external agent retrieves the secret 
and verifies the client, it just needs to do a Compare request to update the 
directory's policy state. Since it has already retrieved the actual 
credentials, it can do a Compare with the current value to indicate a 
successful authentication, and a Compare with some different value to indicate 
a failed authentication. And the issue of bogus requests is mitigated by using 
access controls to restrict who can do search/compare on the authentication 
secret.
-- 
   -- 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: Howard Chu <[email-masked]>
Date: Sat, 15 Aug 2009 04:32:55 -0700

One other point that I almost forgot - the whole issue of intruder detection 
is still rather fragile. E.g., if an attacker is running a stream of guesses 
against a user while the real user logs in, then the successful login will 
erase the current pwdFailureTime state and so allow the attacker a few more 
chances unimpeded.

I suppose this is only a small problem in general. My first response to this 
is that password failures should only be tracked ephemerally, within a 
particular DSA. I would also say they should be tracked by client IP address, 
but these days attacks by botnets makes the value of that approach less clear. 
It's also less effective in an environment using a cluster of load balanced 
DSAs. But I think it still makes more sense to track failures within a single 
DSA than to deal with replication of that state.