Re: [ldapext] Unfinished business: password policy and VLV
Howard Chu <hyc@highlandsun.com> Sat, 04 July 2009 03:02 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 3F7FD3A6CF2 for <ldapext@core3.amsl.com>; Fri, 3 Jul 2009 20:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.161
X-Spam-Level:
X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.438, 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 wvS5YCQjCeW3 for <ldapext@core3.amsl.com>; Fri, 3 Jul 2009 20:02:39 -0700 (PDT)
Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by core3.amsl.com (Postfix) with ESMTP id 32DE03A6BB6 for <ldapext@ietf.org>; Fri, 3 Jul 2009 20:02:39 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id C6E1883EFA; Fri, 3 Jul 2009 23:02:35 -0400 (EDT)
Message-ID: <4A4EC639.3070706@highlandsun.com>
Date: Fri, 03 Jul 2009 20:02:17 -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: John McGarvey <mcgarvey@us.ibm.com>
References: <OFA71CDB2F.9614DC09-ON852573EC.0069861C-852573EC.006BDD73@us.ibm.com>
In-Reply-To: <OFA71CDB2F.9614DC09-ON852573EC.0069861C-852573EC.006BDD73@us.ibm.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: ldapext@ietf.org, Kurt Zeilenga <Kurt.Zeilenga@Isode.com>
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: Sat, 04 Jul 2009 03:02:40 -0000
John McGarvey wrote: > > Kurt, > > It seems questionable to introduce a new password policy approach when > many existing servers implement a form of the Behera draft. I suspect > that the result would not be widely implemented. And another year goes by... I have to agree. Whatever problems exist with the Behera draft should be fixed, rather than launching another completely different proposal. Going thru Appendix A of http://tools.ietf.org/html/draft-zeilenga-ldap-passwords-00 re: the "guessing limit" - as braindead as this feature may be, many sites are required to support it due to Sarbanes-Oxley or various other government regulations. I think the best thing to do here is note that it is bass-ackwards from a security point of view, but because ignorant policy makers require it, it is included in the spec. I.e., provide the feature but fully document why it's a bad feature and provide alternatives to use in its place. re: lockout - it may be beyond the scope of "password policy" management but the solution is needed. In the absence of any additional work occurring in this area in a year and a half, it seems best to simply expand the scope of this spec - to include rudimentary account management - and define formal mechanisms for account expiration and disablement. re: grace logins - time-limited is certainly more sensible. re: disallowing user password changes - ok. re: protocol extension - that section appears to be missing from the draft. While providing this info at other times may be useful, the most common case for users to interact with the password policy machinery is at login time, so it's not clear what other cases you wanted to allow for. If I successfully change my password and get a reply "by the way - your password will expire in 90 days" I will promptly forget it, nor do I actually need to spend any time thinking about it until shortly before it expires again. re: bind and compare - ok, certainly we should discourage use of Compare as an authentication method. re: DSA-generated passwords - ok, let's add this to Behera. re: password min length and max length - ok. re: password history - ok, time-based is better. re: password history storage - it may be a local matter, but I think we should still provide an Informational definition here, because leaving it up to each individual site to implement will cause too much wheel-reinvention and will harm interoperability. At this point we have several years worth of accumulated experience with deployments of the Behera draft. We shouldn't throw that away. Most of the issues you address can be fixed as an incremental revision of Behera. Requests for an absolute expiration/lockout mechanism keep coming up time and again. It's too small a feature to merit its own document. We should simply add a couple new attributes to the existing Policy schema and be done with it. Another item that has come up from my perusal of Kerberos KDC policy - in addition to specifying a time when a password stops being valid, it would be nice to provide an attribute specifying the time when a password *starts* being valid. For password constraints, a regexp constraint would definitely be useful. -- -- 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] Unfinished business: password policy an… John McGarvey
- Re: [ldapext] Unfinished business: password polic… Gavin Henry
- Re: [ldapext] Unfinished business: password polic… John McGarvey
- Re: [ldapext] Unfinished business: password polic… Gavin Henry
- Re: [ldapext] Unfinished business: password polic… Kurt Zeilenga
- Re: [ldapext] Unfinished business: password polic… John McGarvey
- Re: [ldapext] Unfinished business: password polic… Howard Chu
- Re: [ldapext] Unfinished business: password polic… Howard Chu
- Re: [ldapext] Unfinished business: password polic… Jim Willeke
- Re: [ldapext] Unfinished business: password polic… Howard Chu
- Re: [ldapext] Unfinished business: password polic… Kurt Zeilenga
- Re: [ldapext] Unfinished business: password polic… Howard Chu
- Re: [ldapext] Unfinished business: password polic… Howard Chu
- Re: [ldapext] Unfinished business: password polic… Howard Chu
- Re: [ldapext] Unfinished business: password polic… Kurt Zeilenga
- Re: [ldapext] Unfinished business: password polic… Michael Ströder
- Re: [ldapext] Unfinished business: password polic… Howard Chu
- Re: [ldapext] Unfinished business: password polic… Howard Chu