From d.w.chadwick@kent.ac.uk Mon Feb 16 07:44:09 2009 Return-Path: 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 8D0833A67F3 for ; Mon, 16 Feb 2009 07:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 IdVDJtPS+um8 for ; Mon, 16 Feb 2009 07:44:08 -0800 (PST) Received: from mx0.kent.ac.uk (mx0.kent.ac.uk [129.12.21.32]) by core3.amsl.com (Postfix) with ESMTP id 3800C3A6BE0 for ; Mon, 16 Feb 2009 07:44:07 -0800 (PST) Received: from [156.106.219.149] by mx0.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1LZ5dj-0004tp-V6; Mon, 16 Feb 2009 15:44:16 +0000 Message-ID: <499989CD.2020105@kent.ac.uk> Date: Mon, 16 Feb 2009 15:44:13 +0000 From: David Chadwick Organization: University of Kent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: x500standard@freelists.org References: <20080331174501.8F71328C198@core3.amsl.com> <3D27B3E2-C6EA-42AD-BE13-4FD46221E2CA@Isode.com> <01a501c893b7$80659ba0$9801a8c0@softwareaus.com.au> In-Reply-To: <01a501c893b7$80659ba0$9801a8c0@softwareaus.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UKC-SpamScore: - X-UKC-SpamCheck: NO, * -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Mailman-Approved-At: Mon, 16 Feb 2009 08:03:22 -0800 Cc: 'LDAP Extensions list' Subject: Re: [ldapext] [x500standard] Password Policy Administrative Model X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 15:44:09 -0000 Hi Andrew we have just been editing the password policy working document and have addressed the issues you raised in your message below. Andrew Sciberras wrote: > Hi Kurt, > > Just some comments that are specific to the administrative model. > > >> 3. Password Policy Administrative Model > > Administrative Area Scope > In [BEHERA] it was stated that a password policy could be defined for a > specific user by creating a password policy subentry directly under that > entry. To me, this suggests that password policy administrative points act > like specific administrative areas. > Is this behavior intended to remain? > yes. > > Administrative Role > In accordance with X.501 and RFC3672, do you intend to define an > Administrative Role attribute value to identify that a particular > administrative area is concerned with password policy administration? Yes this is defined. > > > Multiple Policies > I assume that the draft allows multiple passwdPolicy subentries to exist > below a given administrative point... Yes this is the case, but no two policies must overlap for the same password attribute type. This should be explicitly clarified in > the I-D. > Multiple subentries could be used to allow policies to apply to different > attributes, Yes, this is now achieved by having a MUST CONTAIN myPwdAttributeTypes attribute in the password policy subentry, which lists the password attribute types that are being covered by this policy. or to allow different policies to apply to a given password > attribute conditionally, No, we dont allow this as it would be too confusing. Which policy would have precedence? based on the objectClass of an entry (~ using > subtreeSpecification's). Yes this is allowed. > However, policies may also be created that inadvertently (or otherwise) > conflict with each other. No this wont be the case, since the directory software should stop a password policy subentry from being created (or an old one being modified) if it causes an overlap of password policies for a given password attribute type in a given subtree. The alternative is to try to define the policy conflict resolution algorithm if two opposing policies apply to a given password attribute in an entry. But this is difficult. For example, what if one policy says encrypt passwords and another says dont. What should the DSA do? Or one policy says encrypt with MD5 and another one says encrypt with AES? > Clarifications on this should probably be made to avoid confusion. I hope we have now clarified the situation. regards David > > > Regards, > Andrew Sciberras > eB2Bcom > > >> -----Original Message----- >> From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org] On Behalf >> Of Kurt Zeilenga >> Sent: Tuesday, 1 April 2008 4:56 AM >> To: LDAP Extensions list >> Cc: x500standard@freelists.org >> Subject: [ldapext] Fwd: I-D Action:draft-zeilenga-ldap-passwords-00.txt >> >> This I-D provides an alternative to draft-behera-ldap-password-policy- >> xx.txt. Appendix provides a discussion of this approach differs, and >> why. >> >> The I-D is a bit rough around the edges... >> >> -- Kurt > > ----- > www.x500standard.com: The central source for information on the X.500 Directory Standard. > > -- Saying that Israel is justified in assaulting Palestine because of Hamas' rockets is like saying the UK should have bombed Belfast when the IRA was active. http://stopwar.org.uk/ ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************