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

Howard Chu <hyc@highlandsun.com> Tue, 07 July 2009 00:37 UTC

Return-Path: <hyc@highlandsun.com>
X-Original-To: ldapext@core3.amsl.com
Delivered-To: ldapext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E38F428C134 for <ldapext@core3.amsl.com>; Mon, 6 Jul 2009 17:37:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKrJ38bDDpmh for <ldapext@core3.amsl.com>; Mon, 6 Jul 2009 17:37:46 -0700 (PDT)
Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by core3.amsl.com (Postfix) with ESMTP id AF0A03A6919 for <ldapext@ietf.org>; Mon, 6 Jul 2009 17:37:46 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id C4B5910F96; Mon, 6 Jul 2009 20:36:16 -0400 (EDT)
Message-ID: <4A52986B.80001@highlandsun.com>
Date: Mon, 06 Jul 2009 17:35:55 -0700
From: Howard Chu <hyc@highlandsun.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.9.1b5pre) Gecko/20090630 SeaMonkey/2.0a1pre Firefox/3.0.3
MIME-Version: 1.0
To: Kurt Zeilenga <Kurt.Zeilenga@Isode.com>
References: <OFA71CDB2F.9614DC09-ON852573EC.0069861C-852573EC.006BDD73@us.ibm.com> <4A4EC639.3070706@highlandsun.com> <E263270E-E8AC-4245-829A-BA98882655D8@Isode.com>
In-Reply-To: <E263270E-E8AC-4245-829A-BA98882655D8@Isode.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: ldapext@ietf.org
Subject: Re: [ldapext] Unfinished business: password policy and VLV
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 07 Jul 2009 00:37:48 -0000

Kurt Zeilenga wrote:
> 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
>   >.

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

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