[ldapext] Working on password policy standardization

Clément OUDOT <clem.oudot@gmail.com> Wed, 18 March 2015 09:37 UTC

Return-Path: <clem.oudot@gmail.com>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AC51A0143 for <ldapext@ietfa.amsl.com>; Wed, 18 Mar 2015 02:37:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1
X-Spam-Level: *
X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4I0AIIOrTmd for <ldapext@ietfa.amsl.com>; Wed, 18 Mar 2015 02:37:06 -0700 (PDT)
Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE5A1A0103 for <ldapext@ietf.org>; Wed, 18 Mar 2015 02:37:06 -0700 (PDT)
Received: by pdbni2 with SMTP id ni2so38039364pdb.1 for <ldapext@ietf.org>; Wed, 18 Mar 2015 02:37:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/MxU1i10DlGY4KlKw9UYYhFisfJfQksZP+Q4hfEb6dc=; b=df4fNPVzwXEmzDZ018kr5frXmmMedcLPgyRfjelqX4JZiA5esGTzeHuLjuRG7JRRV+ nXczxyNWAfN1tL3ndMPhV3NorkpI1J580cNk3n7HiYG0wJ6xAhnI5CNMs6MQcNL87Qo6 RIqZ0V2N5UPu+xDmop6Pt+jLU/pXwCfxt74VNMBmsPAniJGSRtNURA/vXmlYjfpGVNhe +u5oVy2J5D78HlIt0xsQAkTYKYz8MIFXiEJKr66suY5wpq1UoveIOKZrV1biOufexyv5 Fh8U0UNip74Xyj4HARU12Sjgw0OzT+7DiJ40VmY+zjfETPHGAjxgHgg4n7IFnBk+nECs bhZg==
MIME-Version: 1.0
X-Received: by 10.70.96.145 with SMTP id ds17mr160055360pdb.153.1426671425886; Wed, 18 Mar 2015 02:37:05 -0700 (PDT)
Received: by 10.70.45.225 with HTTP; Wed, 18 Mar 2015 02:37:05 -0700 (PDT)
Date: Wed, 18 Mar 2015 10:37:05 +0100
Message-ID: <CAK_oV49mhP3FdbXyZUGfbQ6sSC_zRCMLe=W1vfoXgZKBnxUE3Q@mail.gmail.com>
From: =?UTF-8?Q?Cl=C3=A9ment_OUDOT?= <clem.oudot@gmail.com>
To: ldapext <ldapext@ietf.org>
Content-Type: multipart/mixed; boundary=001a11c20a9c8d512b05118cd33b
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/N1HWtwx3e03KdLVdfAEDZNaANiQ>
Subject: [ldapext] Working on password policy standardization
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldapext/>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Mar 2015 09:37:20 -0000

Hello,

following the mail of Ludovic requesting for help on drafts
standardization, and as proposed by Michael, I would like to start a
discussion on the password policy subject.

As a disclaimer, I would like to say that I never worked on publishing
drafts or RFC, it is my first attempt here. So please feel free to
point out all the mistakes I could do to help me improve this work.



1/ Current situation

We have two drafts on the subject:
* draft-behera-ldap-password-policy-10
* draft-zeilenga-ldap-passwords-00

I join them to this message.

As far as I know, the only implemented draft is the Behera draft, but
only in version 9. This is implemented at least in OpenLDAP, but also
in OpenDJ and ApacheDS (needs confirmation).



2/ Main drawbacks

A list of drawbacks of the Behera draft is presented in Zeilinga draft
in Appendix A. I will not reproduce them all here but focus on the
most important (from my point of view):
* The lock/unlock feature for directory administrators is not clear,
and relies on an operational attributes (pwdAccountLockedTime) that
should not be written by administrators
* There is no time limit for grace authentications
* Disallowing password change should be done with ACL, not ppolicy configuration
* PPolicy do not allow DSA-generated passwords

I would add some others:
* There is no definition of what "directory administrators" are, and
how provide them specific rights to handle password policy
* There is no indication on how apply a password policy to a group of
users (I know there was a discussion on this on ApacheDS mailing list
some days ago)
* The password checker feature is complex to implement. Default
password policy allows to specify min lenght (and max lenght), and
history check. Why not define in the standard policy how to check
different class of characters (upper, lower, digits, etc.)? And also
the possibility to refuse a password containing the value of an
attribute of the entry (uid, cn, etc.)?
* The "password change after reset" feature is also complex to
implement, and often ignored by LDAP clients, as the BIND result is
always true (the password change after reset information is only
present in response control).
* There is not authentication date. This is a common requested
feature. It is for example implemented in lastbind overlay in
OpenLDAP.

And also a remark from Ludovic on this list:
> There was a general consensus that the current password policy draft needs to be split in multiple documents to separate the configuration of it, the internal state representation and the management side of it (controls and possible extended operations).



3/ Goals

* Split password policy drafts in multiple documents :
  - Configuration
  - Internal state representation
  - Management (controls and extended operation)

* Remove all unused features of current drafts (pwdAllowUserChange, ...)

* Clarify all the administration operations, and how to allow them to
directory administrators

* Provide more rules on password policy checking

* Propose a technical solution to apply a password policy to a list of
users (for example with collective attributes)



I would be happy to have your feedback on this message, and advices on
how to advance on this topic.


Clément OUDOT.