From ldapext-bounces@ietf.org Wed Dec 1 12:00:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26543 for ; Wed, 1 Dec 2004 12:00:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZWtK-0004gg-Lf; Wed, 01 Dec 2004 10:59:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZU8p-000425-G3 for ldapext@megatron.ietf.org; Wed, 01 Dec 2004 08:03:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25182 for ; Wed, 1 Dec 2004 08:03:28 -0500 (EST) Received: from ausmtp01.au.ibm.com ([202.81.18.186]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZUE0-000820-Rv for ldapext@ietf.org; Wed, 01 Dec 2004 08:09:01 -0500 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp01.au.ibm.com (8.12.10/8.12.10) with ESMTP id iB1D47hp311430 for ; Thu, 2 Dec 2004 00:04:07 +1100 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.250.243]) by sd0208e0.au.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB1D4T2I075014 for ; Thu, 2 Dec 2004 00:04:29 +1100 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.12.11/8.12.11) with ESMTP id iB1D2eJm024775 for ; Thu, 2 Dec 2004 00:02:40 +1100 Received: from d23m0061.in.ibm.com (d23m0061.in.ibm.com [9.182.216.21]) by d23av02.au.ibm.com (8.12.11/8.12.11) with ESMTP id iB1D2dvv024746; Thu, 2 Dec 2004 00:02:40 +1100 To: "Jim Sermersheim" X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Apurva Kumar Date: Wed, 1 Dec 2004 18:33:06 +0530 X-MIMETrack: Serialize by Router on d23m0061/23/M/IBM(Release 6.51HF653 | October 18, 2004) at 01/12/2004 18:33:44 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ldapext@ietf.org Subject: [ldapext] Distributed Operations: Comments X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Jim, I had a couple of observations on the distributed operations draft (revision: 01): (i) fields like traceInformation and searchedSubtrees have more to do with distributed operations rather than the particular mechanism being used (chaining/referral etc). E.g. looping could occur with referrals, so traceInformation should be included in ContinuationReference. But IMO, a better solution is to delink such control information (visited URIs and searched subtrees) from the operation being progressed and include them as controls. (ii) while the draft considerably simplifies distributed operations from X.518, I feel much less is required to reliably use the referral and chaining mechanisms in LDAP. Existing LDAP mechanisms for referral generation and using referrals for progressing operations are well understood and widely implemented. Chaining is simply following a referral at a DSA instead of the client. These basic mechanisms can be supported by controls which keep track of visited URIs and searched subtrees. E.g. a client or a DSA could include a distributedOperation control: distributedOpControlValue ::= SEQUENCE { visitedURIs SEQUENCE OF LDAPURL, searchedSubtrees SEQUENCE OF LDAPDN OPTIONAL } DSAs encountered as the operation progresses (by either referral or chaining mechanism) will perform loop detection, update these fields (if no loops were found) and send them back in a response control (in case of referral) or include the updated control in chained operation request(s). The response control will also include a result code describing the status of the distributed operation. Regards, Apurva ----- Apurva Kumar, Research Staff Member, IBM India Research Lab Phone: +91-11-26861100 Fax: +91-11-26861555 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Dec 6 13:18:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07506 for ; Mon, 6 Dec 2004 13:18:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbNNx-000830-Gd; Mon, 06 Dec 2004 13:14:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbNJN-0006Zw-QE for ldapext@megatron.ietf.org; Mon, 06 Dec 2004 13:10:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06348 for ; Mon, 6 Dec 2004 13:10:10 -0500 (EST) Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbNPl-0002qU-TY for ldapext@ietf.org; Mon, 06 Dec 2004 13:16:50 -0500 Received: from cacexg12.americas.cpqcorp.net (cacexg12.americas.cpqcorp.net [16.92.1.72]) by palrel12.hp.com (Postfix) with ESMTP id 52EB2414278; Mon, 6 Dec 2004 10:10:11 -0800 (PST) Received: from cacexc10.americas.cpqcorp.net ([16.92.1.47]) by cacexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Dec 2004 10:10:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] Password Policy OIDs Date: Mon, 6 Dec 2004 10:10:02 -0800 Message-ID: <632116003944094FB495E72A6EDB90B281A703@cacexc10.americas.cpqcorp.net> Thread-Topic: [ldapext] Password Policy OIDs Thread-Index: AcTLH9Fm5wmyB+5oQj657NY8jcNX+wQlf9LQ From: "Neal-Joslin, Robert (HP-UX Lab R&D)" To: "John McMeeking" X-OriginalArrivalTime: 06 Dec 2004 18:10:03.0709 (UTC) FILETIME=[CF0AFED0:01C4DBBE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Content-Transfer-Encoding: quoted-printable Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi John, My apologies for a delayed reply. I've been extremely busy, but would still like to follow up. I would just like to follow up on your last question. Are we proposing standard policy rules or a method for extending, and possibly managing, password policy rules? IMHO, we could define a specific set of password policy rules. However, we can not expect that that set of rules would be adequate for a typical deployment. Therefore we need to look at way to allow for extension of password policies. I personally feel that the draft should include a way for customers to define the rules they require for password quality checking, doing so out of a collection of rules. Those rules can be defined by standards bodies, vendors of directory products, third parties or end customers. All we really need is a syntax that allows the directory administrator to select from that set. As an example, I think the syntax should allow the expression of something like the following. Newly created passwords must, follow 3 of the following 4 requirements: 1) Contain at least one alpha or numeric character 2) Not contain a substring of 3 or more characters that matches a word found in either dictionary A or in dictionary B 3) Be at least 7 characters in length or contain at least 5 special characters. 4) Not contain either the cn, sn or telephone number attributes. And the newly created password must 5) Not be constructed using current year, represented numerically. 6) Not be constructed using the current month, represented either as 2 digits or as a substring of 3 or more characters of the name of the month To clarify, my proposal is not that the draft be able to express the details of those rules, just which rules in which combination. I could re-state it as the following... RuleA =3D Character inclusion RuleB =3D Dictionary substring exclusion RuleC =3D Min length=20 RuleD =3D Attribute substring exclusion RuleE =3D Current year exclusion RuleF =3D Current month exclusion Where the syntax might look more like (but not exactly like) Choose 3 OF RuleA "1 of [A-Z,a-z,0-9]"; (RuleB "Dictionary A min 3" AND=20 RuleB "Dictionary B min 3"); (RuleC 7 OR RuleA "5 of [[:Special:]]"); RuleD "cn,sn,telephoneNumber"; AND RuleE AND RuleF My points with the above examples... 1) We can't expect to come up with an adequate set of password quality rules and enumerate them in this draft. 2) We need a somewhat complex syntax just to describe which rules to use. In this example, the password quality policy rules are manageable through LDAP, as long as the rules being used are supported by that directory server. Bob , customer envision defining a way for customers to select from a=20 > -----Original Message----- > From: ldapext-bounces@ietf.org=20 > [mailto:ldapext-bounces@ietf.org] On Behalf Of John McMeeking > Sent: Monday, November 15, 2004 6:19 AM > To: ldapext@ietf.org > Subject: Re: [ldapext] Password Policy OIDs >=20 >=20 >=20 >=20 >=20 > I viewed my posts as describing possible mechanisms for=20 > extending password > policy beyond the "basic" password policy defined in this=20 > draft, one using > attributes and auxiliary classes in a schema defined by the=20 > extension, this > latter providing a predefined attribute for the purpose. I=20 > then drew from > other posts to form examples of how these extension=20 > mechanisms might be > used, not intending that those particular policy extensions - included > characters, excluded characters - be incorporated into the=20 > password policy > document. >=20 > In that context, debate over whether regex's should be used=20 > vs lists of > characters and whether a dictionary should be in LDAP is=20 > largely academic; > it debate over the design of hypothetical future extensions. =20 > If people are > proposing that these be added to the password policy draft,=20 > then it is a > very relevant discussion. >=20 > As to manageability of features from LDAP... I guess that=20 > depends on where > you want to draw the line. I agree that it is nice if you=20 > don't have to > use one set of tools to manage part of the policy and another=20 > to manage the > rest. On the other hand, other tools/storage mechanism may=20 > be much better > suited to managing these than LDAP. I don't think is=20 > necessary to store > the dictionary in LDAP to be able to effectively manage a=20 > password policy > that uses a dictionary. One may want to share an existing=20 > dictionary used > by other applications. Similarly, if one wanted to use=20 > scripts, I don't > think the scripts need to be stored in LDAP. A file name is quite > adequate. Alternately, the password policy parameters could=20 > contain URLs > referencing an LDAP entry containing a dictionary or perl script. >=20 > If I were designing policies dealing with dictionaries or=20 > scripts, I would > consider designing the policy rule description to allow=20 > either to be used. > The dictionary parameter would be a URL, either a file URL or=20 > a LDAP URL. > Script extensions could be handled similarly. >=20 > So, are we talking about adding specific new policy rules to=20 > this document? > Or are we talking about how password policy could be extended? >=20 >=20 > John McMeeking >=20 >=20 > Howard Chu wrote on 11/12/2004 05:23:43 PM: >=20 > > Neal-Joslin, Robert (HP-UX Lab R&D) wrote: > > > Hi John, > > > > > > Yes, that is roughly it. See in-line. > > > > >>Its looks more to me like what Bob really was after was a > > >>policy attribute > > >>that could be used to describe any rule -- assuming the > > >>server understood > > >>it. > > >> > > >>In that light, maybe my suggestion was a bit off the mark - > > >>or at least a > > >>quite different approach to the problem. I think it=20 > would be quite > > >>reasonable to define a multi-valued attribute, say=20 > pwdPolicyRule, that > > >>consisted of three parts: > > >>- name for this rule instance > > >>- OID for the rule it describes (server must implement this rule & > > >>advertise it?) > > >>- parameters for the rule, perhaps in some XML format - or > > >>maybe the whole > > >>attribute in XML. > > > > In general I dislike adding any feature in LDAP that is not=20 > itself also > > manageable by LDAP. But it appears that there may be no other choice > > here. For the Password Policy prototype that Neil Dunbar @=20 > HP wrote, he > > added an attribute specifying the name of an external=20 > executable program > > to be used to validate the password. That punts the=20 > problem, but you can > > no longer view your entire policy with just an LDAP search, you need > > external knowledge. > > > > With respect to external dictionaries, I'd say just use=20 > LDAP search URLs > > and require the dictionary to exist as an LDAP entry. > > > > > XML would be fine, especially for readability. And XML format > > probably should be recommended. But I like the option of leaving > > the encoding up to the implementer. We're assuming that XML would > > suit everyone's needs. More importantly, the I would argue that we > > can't come up with a single DTD. > > > > XML is ok for representing data. But when you are talking about a > > collection of rules and behaviors, what you're talking=20 > about is really a > > program, and what would be best here would be a scripting=20 > language. perl > > would be well suited to the task, and I'm sure there are others. > > > > >>The attribute would use something like a "policy rule name" > > >>matching rule - > > >>i.e. each pwdPolicyRule value must have a unique name. This > > >>would allow > > >>multiple instances of a given rule OID. > > >> > > >>A combination of required chars and excluded character > > >>policies might look > > >>like (pardon my XML): > > >> > > >># requires 2 special characters, 1 from each of these sets: > > >>pwdPolicyRule: rule1 requiredchars-oid chars=3D"!@#$" /> > > >>pwdPolicyRule: rule2 requiredchars-oid chars=3D"%^&" /> > > >># vowels not allowed > > >>pwdPolicyRule: rule3 excludedchars-oid > > >> > > >>I suppose a better version might be: > > >>pwdPolicyRule: chars=3D"aeiouAEIOU" /> > > >> > > > > > > As I hinted in my last message, we may need an optional "Required > > Rule" field. For example, let's suppose I want to encode the > > following policy... > > > > > > "Password must have at least 4 characters and not be in a > > dictionary. It must also contain 3 of the following: 1 upper case > > character, 1 lower case character, 1 character of = '!@#$%^&*()_+=3D[]-' > > or 1 numeric digit. > > > > > > To encode this, I would need a way to specify that "min 4" and > > "not in dictionary" are required. And in addition, I would need a > > rule that says at least 3 of the "non-required" rules must pass. > > > > > > Yes, this is getting ugly. And I don't want to hinder the > > progress of the pwd-policy draft. > > > > -- > > -- Howard Chu > > Chief Architect, Symas Corp. Director, Highland Sun > > http://www.symas.com http://highlandsun.com/hyc > > Symas: Premier OpenSource Development and Support > > > > _______________________________________________ > > Ldapext mailing list > > Ldapext@ietf.org > > https://www1.ietf.org/mailman/listinfo/ldapext >=20 >=20 > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext >=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Dec 8 09:26:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28636 for ; Wed, 8 Dec 2004 09:26:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc2e1-0002SZ-TX; Wed, 08 Dec 2004 09:18:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc2Sc-0007kl-Tt for ldapext@megatron.ietf.org; Wed, 08 Dec 2004 09:06:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26420 for ; Wed, 8 Dec 2004 09:06:29 -0500 (EST) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc2ZO-00069f-PM for ldapext@ietf.org; Wed, 08 Dec 2004 09:13:31 -0500 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 08 Dec 2004 07:05:56 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Wed, 08 Dec 2004 07:04:46 -0700 From: "Jim Sermersheim" To: , Subject: RE: [ldapext] Password Policy OIDs Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d48d865303330c98a6e90d450cf2ff2 Cc: Duane Buss , ldapext@ietf.org, Tammy Green X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1135622645==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============1135622645== Content-Type: multipart/alternative; boundary="=__Part795982EE.1__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part795982EE.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit In general I agree with this approach. For a while I've been thinking that an OID-syntax multi-valued attribute would be sufficient (where each OID represents a rule specified somewhere), and that all rules would always be ANDed (rule specifications could talk more about the semantics of the combinations of certain rules). The specification for any given rule would define mechanisms for the storage of rule-related data (i.e. a dictionary rule might specify that some pwdDictionary attribute be used to hold values like "!(substr(3) dictA)". That way, the list of rules is kept as simple as possible. However, I can see that allowing ORs (and possibly other) operators would be useful. I know a simple syntax allowing AND and OR is not as flexible as what you've described below (where you have "3 of"), but is it sufficient? If we call your criteria below P1 - P6, using only AND and OR we'd have to do this: ( (P1 AND P2 AND P3) OR (P1 AND P2 AND P4) OR (P1 AND P3 AND P4) OR (P2 AND P3 AND P4) ) AND P5 AND P6 Jim >>> "Neal-Joslin, Robert (HP-UX Lab R&D)" 12/6/04 11:10:02 AM >>> Hi John, My apologies for a delayed reply. I've been extremely busy, but would still like to follow up. I would just like to follow up on your last question. Are we proposing standard policy rules or a method for extending, and possibly managing, password policy rules? IMHO, we could define a specific set of password policy rules. However, we can not expect that that set of rules would be adequate for a typical deployment. Therefore we need to look at way to allow for extension of password policies. I personally feel that the draft should include a way for customers to define the rules they require for password quality checking, doing so out of a collection of rules. Those rules can be defined by standards bodies, vendors of directory products, third parties or end customers. All we really need is a syntax that allows the directory administrator to select from that set. As an example, I think the syntax should allow the expression of something like the following. Newly created passwords must, follow 3 of the following 4 requirements: 1) Contain at least one alpha or numeric character 2) Not contain a substring of 3 or more characters that matches a word found in either dictionary A or in dictionary B 3) Be at least 7 characters in length or contain at least 5 special characters. 4) Not contain either the cn, sn or telephone number attributes. And the newly created password must 5) Not be constructed using current year, represented numerically. 6) Not be constructed using the current month, represented either as 2 digits or as a substring of 3 or more characters of the name of the month To clarify, my proposal is not that the draft be able to express the details of those rules, just which rules in which combination. I could re-state it as the following... RuleA = Character inclusion RuleB = Dictionary substring exclusion RuleC = Min length RuleD = Attribute substring exclusion RuleE = Current year exclusion RuleF = Current month exclusion Where the syntax might look more like (but not exactly like) Choose 3 OF RuleA "1 of [A-Z,a-z,0-9]"; (RuleB "Dictionary A min 3" AND RuleB "Dictionary B min 3"); (RuleC 7 OR RuleA "5 of [[:Special:]]"); RuleD "cn,sn,telephoneNumber"; AND RuleE AND RuleF My points with the above examples... 1) We can't expect to come up with an adequate set of password quality rules and enumerate them in this draft. 2) We need a somewhat complex syntax just to describe which rules to use. In this example, the password quality policy rules are manageable through LDAP, as long as the rules being used are supported by that directory server. Bob , customer envision defining a way for customers to select from a > -----Original Message----- > From: ldapext-bounces@ietf.org > [mailto:ldapext-bounces@ietf.org] On Behalf Of John McMeeking > Sent: Monday, November 15, 2004 6:19 AM > To: ldapext@ietf.org > Subject: Re: [ldapext] Password Policy OIDs > > > > > > I viewed my posts as describing possible mechanisms for > extending password > policy beyond the "basic" password policy defined in this > draft, one using > attributes and auxiliary classes in a schema defined by the > extension, this > latter providing a predefined attribute for the purpose. I > then drew from > other posts to form examples of how these extension > mechanisms might be > used, not intending that those particular policy extensions - included > characters, excluded characters - be incorporated into the > password policy > document. > > In that context, debate over whether regex's should be used > vs lists of > characters and whether a dictionary should be in LDAP is > largely academic; > it debate over the design of hypothetical future extensions. > If people are > proposing that these be added to the password policy draft, > then it is a > very relevant discussion. > > As to manageability of features from LDAP... I guess that > depends on where > you want to draw the line. I agree that it is nice if you > don't have to > use one set of tools to manage part of the policy and another > to manage the > rest. On the other hand, other tools/storage mechanism may > be much better > suited to managing these than LDAP. I don't think is > necessary to store > the dictionary in LDAP to be able to effectively manage a > password policy > that uses a dictionary. One may want to share an existing > dictionary used > by other applications. Similarly, if one wanted to use > scripts, I don't > think the scripts need to be stored in LDAP. A file name is quite > adequate. Alternately, the password policy parameters could > contain URLs > referencing an LDAP entry containing a dictionary or perl script. > > If I were designing policies dealing with dictionaries or > scripts, I would > consider designing the policy rule description to allow > either to be used. > The dictionary parameter would be a URL, either a file URL or > a LDAP URL. > Script extensions could be handled similarly. > > So, are we talking about adding specific new policy rules to > this document? > Or are we talking about how password policy could be extended? > > > John McMeeking > > > Howard Chu < hyc@highlandsun.com > wrote on 11/12/2004 05:23:43 PM: > > > Neal-Joslin, Robert (HP-UX Lab R&D) wrote: > > > Hi John, > > > > > > Yes, that is roughly it. See in-line. > > > > >>Its looks more to me like what Bob really was after was a > > >>policy attribute > > >>that could be used to describe any rule -- assuming the > > >>server understood > > >>it. > > >> > > >>In that light, maybe my suggestion was a bit off the mark - > > >>or at least a > > >>quite different approach to the problem. I think it > would be quite > > >>reasonable to define a multi-valued attribute, say > pwdPolicyRule, that > > >>consisted of three parts: > > >>- name for this rule instance > > >>- OID for the rule it describes (server must implement this rule & > > >>advertise it?) > > >>- parameters for the rule, perhaps in some XML format - or > > >>maybe the whole > > >>attribute in XML. > > > > In general I dislike adding any feature in LDAP that is not > itself also > > manageable by LDAP. But it appears that there may be no other choice > > here. For the Password Policy prototype that Neil Dunbar @ > HP wrote, he > > added an attribute specifying the name of an external > executable program > > to be used to validate the password. That punts the > problem, but you can > > no longer view your entire policy with just an LDAP search, you need > > external knowledge. > > > > With respect to external dictionaries, I'd say just use > LDAP search URLs > > and require the dictionary to exist as an LDAP entry. > > > > > XML would be fine, especially for readability. And XML format > > probably should be recommended. But I like the option of leaving > > the encoding up to the implementer. We're assuming that XML would > > suit everyone's needs. More importantly, the I would argue that we > > can't come up with a single DTD. > > > > XML is ok for representing data. But when you are talking about a > > collection of rules and behaviors, what you're talking > about is really a > > program, and what would be best here would be a scripting > language. perl > > would be well suited to the task, and I'm sure there are others. > > > > >>The attribute would use something like a "policy rule name" > > >>matching rule - > > >>i.e. each pwdPolicyRule value must have a unique name. This > > >>would allow > > >>multiple instances of a given rule OID. > > >> > > >>A combination of required chars and excluded character > > >>policies might look > > >>like (pardon my XML): > > >> > > >># requires 2 special characters, 1 from each of these sets: > > >>pwdPolicyRule: rule1 requiredchars-oid chars="!@#$" /> > > >>pwdPolicyRule: rule2 requiredchars-oid chars="%^&" /> > > >># vowels not allowed > > >>pwdPolicyRule: rule3 excludedchars-oid > > >> > > >>I suppose a better version might be: > > >>pwdPolicyRule: chars="aeiouAEIOU" /> > > >> > > > > > > As I hinted in my last message, we may need an optional "Required > > Rule" field. For example, let's suppose I want to encode the > > following policy... > > > > > > "Password must have at least 4 characters and not be in a > > dictionary. It must also contain 3 of the following: 1 upper case > > character, 1 lower case character, 1 character of '!@#$%^&*()_+=[]-' > > or 1 numeric digit. > > > > > > To encode this, I would need a way to specify that "min 4" and > > "not in dictionary" are required. And in addition, I would need a > > rule that says at least 3 of the "non-required" rules must pass. > > > > > > Yes, this is getting ugly. And I don't want to hinder the > > progress of the pwd-policy draft. > > > > -- > > -- Howard Chu > > Chief Architect, Symas Corp. Director, Highland Sun > > http://www.symas.com http://highlandsun.com/hyc > > Symas: Premier OpenSource Development and Support > > > > _______________________________________________ > > Ldapext mailing list > > Ldapext@ietf.org > > https://www1.ietf.org/mailman/listinfo/ldapext > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__Part795982EE.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In general I agree with this approach. For a while I've been = thinking that an OID-syntax multi-valued attribute would be sufficient= (where each OID represents a rule specified somewhere), and that all = rules would always be ANDed (rule specifications could talk more about the = semantics of the combinations of certain rules). The specification for any = given rule would define mechanisms for the storage of rule-related data = (i.e. a dictionary rule might specify that some pwdDictionary attribute be = used to hold values like "!(substr(3) dictA)". That way, the list of rules = is kept as simple as possible.
 
However, I can see that allowing ORs (and possibly other) operators = would be useful.
I know a simple syntax allowing AND and OR is not as flexible as what = you've described below (where you have "3 of"), but is it sufficient? If = we call your criteria below P1 - P6, using only AND and OR we'd have to do = this:
(  (P1 AND P2 AND P3)
OR (P1 AND P2 AND P4)
OR (P1 AND P3 AND P4)
OR (P2 = AND P3 AND P4)
)
AND P5
AND P6
 
Jim

>>> "Neal-Joslin, Robert (HP-UX Lab R&D)" <bob.jos= lin@hp.com> 12/6/04 11:10:02 AM >>>
Hi John,

My = apologies for a delayed reply. I've been extremely busy, but would
still= like to follow up.

I would just like to follow up on your last = question. Are we proposing
standard policy rules or a method for = extending, and possibly managing,
password policy rules? IMHO, we could = define a specific set of password
policy rules. However, we can not = expect that that set of rules would
be adequate for a typical deployment= . Therefore we need to look at way
to allow for extension of password = policies.

I personally feel that the draft should include a way for = customers to
define the rules they require for password quality = checking, doing so
out of a collection of rules. Those rules can be = defined by standards
bodies, vendors of directory products, third = parties or end customers.
All we really need is a syntax that allows = the directory administrator
to select from that set. As an example, I = think the syntax should allow
the expression of something like the = following.

Newly created passwords must, follow 3 of the following = 4
requirements:

1) Contain at least one alpha or numeric = character
2) Not contain a substring of 3 or more characters that = matches
a word found in either dictionary A or in dictionary B
3) Be = at least 7 characters in length or contain at least 5 special
characters= .
4) Not contain either the cn, sn or telephone number attributes.
And the newly created password must

5) Not be constructed using = current year, represented numerically.
6) Not be constructed using the = current month, represented either as
2 digits or as a substring of 3 or = more characters of the name
of the month

To clarify, my proposal = is not that the draft be able to express the
details of those rules, = just which rules in which combination. I could
re-state it as the = following...

RuleA =3D Character inclusion
RuleB =3D Dictionary = substring exclusion
RuleC =3D Min length
RuleD =3D Attribute = substring exclusion
RuleE =3D Current year exclusion
RuleF =3D = Current month exclusion

Where the syntax might look more like (but = not exactly like)

Choose 3 OF
RuleA "1 of [A-Z,a-z,0-9]";
(Rul= eB "Dictionary A min 3" AND
RuleB "Dictionary B min 3");
(RuleC 7 = OR RuleA "5 of [[:Special:]]");
RuleD "cn,sn,telephoneNumber";
AND = RuleE
AND RuleF

My points with the above examples... 1) We can't = expect to come up with
an adequate set of password quality rules and = enumerate them in this
draft. 2) We need a somewhat complex syntax just = to describe which
rules to use.

In this example, the password = quality policy rules are manageable
through LDAP, as long as the rules = being used are supported by that
directory server.

Bob

, = customer envision defining a way for customers to select from a
> = -----Original Message-----
> From: ldapext-bounces@ietf.org
> [mailto:ldapext-bounces@ietf.org] On Behalf Of John McMeeking
> Sent: Monday, November 15, 2004 = 6:19 AM
> To: ldapext@ietf.org=
> Subject: Re: [ldapext] Password Policy OIDs
> =
>
>
>
>
> I viewed my posts as = describing possible mechanisms for
> extending password
> = policy beyond the "basic" password policy defined in this
> draft, = one using
> attributes and auxiliary classes in a schema defined by = the
> extension, this
> latter providing a predefined = attribute for the purpose. I
> then drew from
> other posts = to form examples of how these extension
> mechanisms might = be
> used, not intending that those particular policy extensions - = included
> characters, excluded characters - be incorporated into = the
> password policy
> document.
>
> In that = context, debate over whether regex's should be used
> vs lists = of
> characters and whether a dictionary should be in LDAP is =
> largely academic;
> it debate over the design of hypothetica= l future extensions.
> If people are
> proposing that these = be added to the password policy draft,
> then it is a
> very = relevant discussion.
>
> As to manageability of features from = LDAP... I guess that
> depends on where
> you want to draw = the line. I agree that it is nice if you
> don't have to
> = use one set of tools to manage part of the policy and another
> to = manage the
> rest. On the other hand, other tools/storage mechanism = may
> be much better
> suited to managing these than LDAP. I = don't think is
> necessary to store
> the dictionary in LDAP = to be able to effectively manage a
> password policy
> that = uses a dictionary. One may want to share an existing
> dictionary = used
> by other applications. Similarly, if one wanted to use =
> scripts, I don't
> think the scripts need to be stored in = LDAP. A file name is quite
> adequate. Alternately, the password = policy parameters could
> contain URLs
> referencing an LDAP = entry containing a dictionary or perl script.
>
> If I were = designing policies dealing with dictionaries or
> scripts, I = would
> consider designing the policy rule description to allow =
> either to be used.
> The dictionary parameter would be a = URL, either a file URL or
> a LDAP URL.
> Script extensions = could be handled similarly.
>
> So, are we talking about = adding specific new policy rules to
> this document?
> Or are = we talking about how password policy could be extended?
>
> =
> John McMeeking
>
>
> Howard Chu < hyc@highlandsun.com > wrote = on 11/12/2004 05:23:43 PM:
>
> > Neal-Joslin, Robert = (HP-UX Lab R&D) wrote:
> > > Hi John,
> > = >
> > > Yes, that is roughly it. See in-line.
> = >
> > >>Its looks more to me like what Bob really was = after was a
> > >>policy attribute
> > >>that= could be used to describe any rule -- assuming the
> > >>se= rver understood
> > >>it.
> > >>
> = > >>In that light, maybe my suggestion was a bit off the mark = -
> > >>or at least a
> > >>quite different = approach to the problem. I think it
> would be quite
> > = >>reasonable to define a multi-valued attribute, say
> = pwdPolicyRule, that
> > >>consisted of three parts:
> = > >>- name for this rule instance
> > >>- OID for = the rule it describes (server must implement this rule &
> > = >>advertise it?)
> > >>- parameters for the rule, = perhaps in some XML format - or
> > >>maybe the whole
>= ; > >>attribute in XML.
> >
> > In general I = dislike adding any feature in LDAP that is not
> itself also
>= > manageable by LDAP. But it appears that there may be no other = choice
> > here. For the Password Policy prototype that Neil = Dunbar @
> HP wrote, he
> > added an attribute specifying = the name of an external
> executable program
> > to be = used to validate the password. That punts the
> problem, but you = can
> > no longer view your entire policy with just an LDAP = search, you need
> > external knowledge.
> >
> = > With respect to external dictionaries, I'd say just use
> LDAP = search URLs
> > and require the dictionary to exist as an LDAP = entry.
> >
> > > XML would be fine, especially for = readability. And XML format
> > probably should be recommended. = But I like the option of leaving
> > the encoding up to the = implementer. We're assuming that XML would
> > suit everyone's = needs. More importantly, the I would argue that we
> > can't come = up with a single DTD.
> >
> > XML is ok for representing = data. But when you are talking about a
> > collection of rules = and behaviors, what you're talking
> about is really a
> > = program, and what would be best here would be a scripting
> = language. perl
> > would be well suited to the task, and I'm sure = there are others.
> >
> > >>The attribute would = use something like a "policy rule name"
> > >>matching rule = -
> > >>i.e. each pwdPolicyRule value must have a unique = name. This
> > >>would allow
> > >>multiple = instances of a given rule OID.
> > >>
> > = >>A combination of required chars and excluded character
> = > >>policies might look
> > >>like (pardon my = XML):
> > >>
> > >># requires 2 special = characters, 1 from each of these sets:
> > >>pwdPolicyRule: = rule1 requiredchars-oid <rule count=3D"1"
> chars=3D"!@#$" = />
> > >>pwdPolicyRule: rule2 requiredchars-oid <rule = count=3D"1"
> chars=3D"%^&" />
> > >># vowels = not allowed
> > >>pwdPolicyRule: rule3 excludedchars-oid = <rule chars=3D"aeiouAEIOU" />
> > >>
> > = >>I suppose a better version might be:
> > >>pwdPolicy= Rule: <excludedCharsRule name=3D"rule3"
> chars=3D"aeiouAEIOU" = />
> > >>
> > >
> > > As I = hinted in my last message, we may need an optional "Required
> > = Rule" field. For example, let's suppose I want to encode the
> > = following policy...
> > >
> > > "Password must = have at least 4 characters and not be in a
> > dictionary. It = must also contain 3 of the following: 1 upper case
> > character, = 1 lower case character, 1 character of '!@#$%^&*()_+=3D[]-'
> = > or 1 numeric digit.
> > >
> > > To encode = this, I would need a way to specify that "min 4" and
> > "not in = dictionary" are required. And in addition, I would need a
> > = rule that says at least 3 of the "non-required" rules must pass.
> = > >
> > > Yes, this is getting ugly. And I don't want to = hinder the
> > progress of the pwd-policy draft.
> = >
> > --
> > -- Howard Chu
> > Chief = Architect, Symas Corp. Director, Highland Sun
> > http://www.symas.com http://highlandsun.com/hyc
> > Symas: = Premier OpenSource Development and Support
> >
> > = _______________________________________________
> > Ldapext = mailing list
> > Ldapext@ie= tf.org
> > https://www1.ietf.org/mailman/listinfo/ldapext =
>
>
> _______________________________________________<= BR>> Ldapext mailing list
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext
>

_______________________________________________
Ldape= xt mailing list
Ldapext@ietf.org<= /A>
h= ttps://www1.ietf.org/mailman/listinfo/ldapext
--=__Part795982EE.1__=-- --===============1135622645== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============1135622645==-- From ldapext-bounces@ietf.org Wed Dec 8 12:39:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17187 for ; Wed, 8 Dec 2004 12:39:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc5ew-0003oo-8i; Wed, 08 Dec 2004 12:31:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc5UV-0001Kn-4o for ldapext@megatron.ietf.org; Wed, 08 Dec 2004 12:20:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15708 for ; Wed, 8 Dec 2004 12:20:36 -0500 (EST) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc5bH-0002d2-Sr for ldapext@ietf.org; Wed, 08 Dec 2004 12:27:41 -0500 Received: from cacexg13.americas.cpqcorp.net (cacexg13.americas.cpqcorp.net [16.92.1.76]) by palrel11.hp.com (Postfix) with ESMTP id 3C7EC2F115; Wed, 8 Dec 2004 09:20:35 -0800 (PST) Received: from cacexc10.americas.cpqcorp.net ([16.92.1.47]) by cacexg13.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Dec 2004 09:20:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ldapext] Password Policy OIDs Date: Wed, 8 Dec 2004 09:20:16 -0800 Message-ID: <632116003944094FB495E72A6EDB90B281AC2E@cacexc10.americas.cpqcorp.net> Thread-Topic: [ldapext] Password Policy OIDs Thread-Index: AcTdLxMJTuDae0P7SzOrg/wqa3nqZwAD5RCA From: "Neal-Joslin, Robert (HP-UX Lab R&D)" To: "Jim Sermersheim" , X-OriginalArrivalTime: 08 Dec 2004 17:20:17.0082 (UTC) FILETIME=[2FB361A0:01C4DD4A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3adba28c47054ea827843deea22a7215 Cc: Duane Buss , ldapext@ietf.org, Tammy Green X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0086076612==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a multi-part message in MIME format. --===============0086076612== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4DD4A.2F7763A2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4DD4A.2F7763A2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, =20 Thanks for the reply. =20 I did consider using combinations of rules, to help simplify the logic syntax. And I would be happy with it too. But the two main reasons I proposed the "# of" syntax is... First, the number of combinations grow exponentially. Second, when you have to specify arguments to the rule, you need to re-specify a perhaps large set of the same arguments over and over (I need some clarifications on how you propose passing arguments into rules. See below.) =20 I think the real question is, is the "# of" expression valuable? I know of a couple of customers that depend on it for password quality checking. But does that mean we need it? Should LDAP directory servers provide the ultimate password quality checking semantics? =20 On the second point, I'd like to clarify the question I have above about arguments to rules. You said "The specification for any given rule would define mechanisms for the storage of rule-related data." This sounds like something I was proposing earlier, that each rule would need to have it's own set of arguments that it would interpret. This argument list would be a specified within the rule syntax, but would be a data blob. And that no elements within the argument data blob would need to be specified or interpreted by the syntax. Correct? I assume that when you specified the example below, that P1 represents rule1 along with the arguments to rule1. =20 To me I think it's necessary to have the ability to specify arguments to the rules within the pwdQualityRules attribute. For example, suppose we have the "Minimum number of characters" rule. It seems that an argument is required to specify what specific number of characters is the minimum. I suppose it's possible to specify that argument elsewhere, perhaps in a configuration file that the is known to the rule. But that would make it harder to specify a rule set such as "Password must contain at least 10 characters, or be at least 7 characters long and contain a special character." =20 Thanks =20 Bob =20 =20 ________________________________ From: Jim Sermersheim [mailto:jimse@novell.com]=20 Sent: Wednesday, December 08, 2004 6:05 AM To: Neal-Joslin, Robert (HP-UX Lab R&D); jmcmeek@us.ibm.com Cc: ldapext@ietf.org; Duane Buss; Tammy Green Subject: RE: [ldapext] Password Policy OIDs In general I agree with this approach. For a while I've been thinking that an OID-syntax multi-valued attribute would be sufficient (where each OID represents a rule specified somewhere), and that all rules would always be ANDed (rule specifications could talk more about the semantics of the combinations of certain rules). The specification for any given rule would define mechanisms for the storage of rule-related data (i.e. a dictionary rule might specify that some pwdDictionary attribute be used to hold values like "!(substr(3) dictA)". That way, the list of rules is kept as simple as possible. =20 However, I can see that allowing ORs (and possibly other) operators would be useful. =09 I know a simple syntax allowing AND and OR is not as flexible as what you've described below (where you have "3 of"), but is it sufficient? If we call your criteria below P1 - P6, using only AND and OR we'd have to do this: ( (P1 AND P2 AND P3)=20 OR (P1 AND P2 AND P4) =09 =09 OR (P1 AND P3 AND P4) OR (P2 AND P3 AND P4) )=20 AND P5 AND P6 =20 Jim >>> "Neal-Joslin, Robert (HP-UX Lab R&D)" 12/6/04 11:10:02 AM >>> Hi John, =09 My apologies for a delayed reply. I've been extremely busy, but would still like to follow up. =09 I would just like to follow up on your last question. Are we proposing standard policy rules or a method for extending, and possibly managing, password policy rules? IMHO, we could define a specific set of password policy rules. However, we can not expect that that set of rules would be adequate for a typical deployment. Therefore we need to look at way to allow for extension of password policies. =09 I personally feel that the draft should include a way for customers to define the rules they require for password quality checking, doing so out of a collection of rules. Those rules can be defined by standards bodies, vendors of directory products, third parties or end customers. All we really need is a syntax that allows the directory administrator to select from that set. As an example, I think the syntax should allow the expression of something like the following. =09 Newly created passwords must, follow 3 of the following 4 requirements: =09 1) Contain at least one alpha or numeric character 2) Not contain a substring of 3 or more characters that matches a word found in either dictionary A or in dictionary B 3) Be at least 7 characters in length or contain at least 5 special characters. 4) Not contain either the cn, sn or telephone number attributes. =09 And the newly created password must =09 5) Not be constructed using current year, represented numerically. 6) Not be constructed using the current month, represented either as 2 digits or as a substring of 3 or more characters of the name of the month =09 To clarify, my proposal is not that the draft be able to express the details of those rules, just which rules in which combination. I could re-state it as the following... =09 RuleA =3D Character inclusion RuleB =3D Dictionary substring exclusion RuleC =3D Min length=20 RuleD =3D Attribute substring exclusion RuleE =3D Current year exclusion RuleF =3D Current month exclusion =09 Where the syntax might look more like (but not exactly like) =09 Choose 3 OF RuleA "1 of [A-Z,a-z,0-9]"; (RuleB "Dictionary A min 3" AND=20 RuleB "Dictionary B min 3"); (RuleC 7 OR RuleA "5 of [[:Special:]]"); RuleD "cn,sn,telephoneNumber"; AND RuleE AND RuleF =09 My points with the above examples... 1) We can't expect to come up with an adequate set of password quality rules and enumerate them in this draft. 2) We need a somewhat complex syntax just to describe which rules to use. =09 In this example, the password quality policy rules are manageable through LDAP, as long as the rules being used are supported by that directory server. =09 Bob =09 , customer envision defining a way for customers to select from a=20 > -----Original Message----- > From: ldapext-bounces@ietf.org=20 > [mailto:ldapext-bounces@ietf.org] On Behalf Of John McMeeking > Sent: Monday, November 15, 2004 6:19 AM > To: ldapext@ietf.org=20 > Subject: Re: [ldapext] Password Policy OIDs >=20 >=20 >=20 >=20 >=20 > I viewed my posts as describing possible mechanisms for=20 > extending password > policy beyond the "basic" password policy defined in this=20 > draft, one using > attributes and auxiliary classes in a schema defined by the=20 > extension, this > latter providing a predefined attribute for the purpose. I=20 > then drew from > other posts to form examples of how these extension=20 > mechanisms might be > used, not intending that those particular policy extensions - included > characters, excluded characters - be incorporated into the=20 > password policy > document. >=20 > In that context, debate over whether regex's should be used=20 > vs lists of > characters and whether a dictionary should be in LDAP is=20 > largely academic; > it debate over the design of hypothetical future extensions.=20 > If people are > proposing that these be added to the password policy draft,=20 > then it is a > very relevant discussion. >=20 > As to manageability of features from LDAP... I guess that=20 > depends on where > you want to draw the line. I agree that it is nice if you=20 > don't have to > use one set of tools to manage part of the policy and another=20 > to manage the > rest. On the other hand, other tools/storage mechanism may=20 > be much better > suited to managing these than LDAP. I don't think is=20 > necessary to store > the dictionary in LDAP to be able to effectively manage a=20 > password policy > that uses a dictionary. One may want to share an existing=20 > dictionary used > by other applications. Similarly, if one wanted to use=20 > scripts, I don't > think the scripts need to be stored in LDAP. A file name is quite > adequate. Alternately, the password policy parameters could=20 > contain URLs > referencing an LDAP entry containing a dictionary or perl script. >=20 > If I were designing policies dealing with dictionaries or=20 > scripts, I would > consider designing the policy rule description to allow=20 > either to be used. > The dictionary parameter would be a URL, either a file URL or=20 > a LDAP URL. > Script extensions could be handled similarly. >=20 > So, are we talking about adding specific new policy rules to=20 > this document? > Or are we talking about how password policy could be extended? >=20 >=20 > John McMeeking >=20 >=20 > Howard Chu < hyc@highlandsun.com > wrote on 11/12/2004 05:23:43 PM: >=20 > > Neal-Joslin, Robert (HP-UX Lab R&D) wrote: > > > Hi John, > > > > > > Yes, that is roughly it. See in-line. > > > > >>Its looks more to me like what Bob really was after was a > > >>policy attribute > > >>that could be used to describe any rule -- assuming the > > >>server understood > > >>it. > > >> > > >>In that light, maybe my suggestion was a bit off the mark - > > >>or at least a > > >>quite different approach to the problem. I think it=20 > would be quite > > >>reasonable to define a multi-valued attribute, say=20 > pwdPolicyRule, that > > >>consisted of three parts: > > >>- name for this rule instance > > >>- OID for the rule it describes (server must implement this rule & > > >>advertise it?) > > >>- parameters for the rule, perhaps in some XML format - or > > >>maybe the whole > > >>attribute in XML. > > > > In general I dislike adding any feature in LDAP that is not=20 > itself also > > manageable by LDAP. But it appears that there may be no other choice > > here. For the Password Policy prototype that Neil Dunbar @=20 > HP wrote, he > > added an attribute specifying the name of an external=20 > executable program > > to be used to validate the password. That punts the=20 > problem, but you can > > no longer view your entire policy with just an LDAP search, you need > > external knowledge. > > > > With respect to external dictionaries, I'd say just use=20 > LDAP search URLs > > and require the dictionary to exist as an LDAP entry. > > > > > XML would be fine, especially for readability. And XML format > > probably should be recommended. But I like the option of leaving > > the encoding up to the implementer. We're assuming that XML would > > suit everyone's needs. More importantly, the I would argue that we > > can't come up with a single DTD. > > > > XML is ok for representing data. But when you are talking about a > > collection of rules and behaviors, what you're talking=20 > about is really a > > program, and what would be best here would be a scripting=20 > language. perl > > would be well suited to the task, and I'm sure there are others. > > > > >>The attribute would use something like a "policy rule name" > > >>matching rule - > > >>i.e. each pwdPolicyRule value must have a unique name. This > > >>would allow > > >>multiple instances of a given rule OID. > > >> > > >>A combination of required chars and excluded character > > >>policies might look > > >>like (pardon my XML): > > >> > > >># requires 2 special characters, 1 from each of these sets: > > >>pwdPolicyRule: rule1 requiredchars-oid chars=3D"!@#$" /> > > >>pwdPolicyRule: rule2 requiredchars-oid chars=3D"%^&" /> > > >># vowels not allowed > > >>pwdPolicyRule: rule3 excludedchars-oid > > >> > > >>I suppose a better version might be: > > >>pwdPolicyRule: chars=3D"aeiouAEIOU" /> > > >> > > > > > > As I hinted in my last message, we may need an optional "Required > > Rule" field. For example, let's suppose I want to encode the > > following policy... > > > > > > "Password must have at least 4 characters and not be in a > > dictionary. It must also contain 3 of the following: 1 upper case > > character, 1 lower case character, 1 character of '!@#$%^&*()_+=3D[]-' > > or 1 numeric digit. > > > > > > To encode this, I would need a way to specify that "min 4" and > > "not in dictionary" are required. And in addition, I would need a > > rule that says at least 3 of the "non-required" rules must pass. > > > > > > Yes, this is getting ugly. And I don't want to hinder the > > progress of the pwd-policy draft. > > > > -- > > -- Howard Chu > > Chief Architect, Symas Corp. Director, Highland Sun > > http://www.symas.com http://highlandsun.com/hyc=20 > > Symas: Premier OpenSource Development and Support > > > > _______________________________________________ > > Ldapext mailing list > > Ldapext@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/ldapext=20 >=20 >=20 > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/ldapext=20 >=20 =09 _______________________________________________ Ldapext mailing list Ldapext@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ldapext=20 =09 ------_=_NextPart_001_01C4DD4A.2F7763A2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi = Jim,
 
Thanks for = the=20 reply.
 
I did = consider using=20 combinations of rules, to help simplify the logic syntax.  And I = would be=20 happy with it too.  But the two main reasons I proposed the "# of" = syntax=20 is... First, the number of combinations grow exponentially.  = Second, when=20 you have to specify arguments to the rule, you need to re-specify a = perhaps=20 large set of the same arguments over and over (I need some = clarifications on how=20 you propose passing arguments into rules.  See below.)
 
I think the = real question=20 is, is the "# of" expression valuable?  I know of a couple of = customers=20 that depend on it for password quality checking.  But does that = mean we=20 need it?  Should LDAP directory servers provide the ultimate = password=20 quality checking semantics?
 
On the = second point, I'd=20 like to clarify the question I have above about arguments to = rules.  You=20 said "The specification for any given rule would define mechanisms for = the=20 storage of rule-related data."  This sounds like something I was = proposing=20 earlier, that each rule would need to have it's own set of arguments = that it=20 would interpret.  This argument list would be a specified within = the rule=20 syntax, but would be a data blob.  And that no elements within = the=20 argument data blob would need to be specified or interpreted by the = syntax.  Correct?  I assume that when you specified the = example below,=20 that P1 represents rule1 along with the arguments to rule1.
 
To me I = think it's=20 necessary to have the ability to specify arguments to the rules within = the=20 pwdQualityRules attribute.  For example, suppose we have the = "Minimum=20 number of characters" rule.  It seems that an argument is required = to=20 specify what specific number of characters is the minimum.  I = suppose it's=20 possible to specify that argument elsewhere, perhaps in a configuration = file=20 that the is known to the rule.  But that would make it harder to = specify a=20 rule set such as "Password must contain at least 10 characters, or be at = least 7=20 characters long and contain a special character."
 
Thanks
 
Bob
 
 
From: Jim Sermersheim = [mailto:jimse@novell.com]=20
Sent: Wednesday, December 08, 2004 6:05 AM
To: = Neal-Joslin,=20 Robert (HP-UX Lab R&D); jmcmeek@us.ibm.com
Cc: = ldapext@ietf.org;=20 Duane Buss; Tammy Green
Subject: RE: [ldapext] Password Policy = OIDs

In general I agree with this approach. For a while I've been=20 thinking that an OID-syntax multi-valued attribute would be = sufficient=20 (where each OID represents a rule specified somewhere), and that all = rules=20 would always be ANDed (rule specifications could talk more about the = semantics=20 of the combinations of certain rules). The specification for any given = rule=20 would define mechanisms for the storage of rule-related data (i.e. a=20 dictionary rule might specify that some pwdDictionary attribute be = used to=20 hold values like "!(substr(3) dictA)". That way, the list of rules is = kept as=20 simple as possible.
 
However, I can see that allowing ORs (and possibly other) = operators would=20 be useful.
I know a simple syntax allowing AND and OR is not as flexible as = what=20 you've described below (where you have "3 of"), but is it sufficient? = If we=20 call your criteria below P1 - P6, using only AND and OR we'd have to = do=20 this:
(  (P1 AND P2 AND P3) =
OR (P1 AND P2 AND P4)
OR (P1 AND P3 AND P4)
OR = (P2 AND P3=20 AND P4)
)
AND P5
AND P6
 
Jim

>>> "Neal-Joslin, Robert (HP-UX Lab R&D)"=20 <bob.joslin@hp.com> 12/6/04 11:10:02 AM >>>
Hi=20 John,

My apologies for a delayed reply. I've been extremely = busy, but=20 would
still like to follow up.

I would just like to follow = up on=20 your last question. Are we proposing
standard policy rules or a = method for=20 extending, and possibly managing,
password policy rules? IMHO, we = could=20 define a specific set of password
policy rules. However, we can not = expect=20 that that set of rules would
be adequate for a typical deployment.=20 Therefore we need to look at way
to allow for extension of password = policies.

I personally feel that the draft should include a way = for=20 customers to
define the rules they require for password quality = checking,=20 doing so
out of a collection of rules. Those rules can be defined = by=20 standards
bodies, vendors of directory products, third parties or = end=20 customers.
All we really need is a syntax that allows the directory = administrator
to select from that set. As an example, I think the = syntax=20 should allow
the expression of something like the = following.

Newly=20 created passwords must, follow 3 of the following = 4
requirements:

1)=20 Contain at least one alpha or numeric character
2) Not contain a = substring=20 of 3 or more characters that matches
a word found in either = dictionary A or=20 in dictionary B
3) Be at least 7 characters in length or contain at = least 5=20 special
characters.
4) Not contain either the cn, sn or = telephone number=20 attributes.

And the newly created password must

5) Not = be=20 constructed using current year, represented numerically.
6) Not be=20 constructed using the current month, represented either as
2 digits = or as a=20 substring of 3 or more characters of the name
of the = month

To=20 clarify, my proposal is not that the draft be able to express = the
details=20 of those rules, just which rules in which combination. I = could
re-state it=20 as the following...

RuleA =3D Character inclusion
RuleB =3D = Dictionary=20 substring exclusion
RuleC =3D Min length
RuleD =3D Attribute = substring=20 exclusion
RuleE =3D Current year exclusion
RuleF =3D Current = month=20 exclusion

Where the syntax might look more like (but not = exactly=20 like)

Choose 3 OF
RuleA "1 of [A-Z,a-z,0-9]";
(RuleB = "Dictionary=20 A min 3" AND
RuleB "Dictionary B min 3");
(RuleC 7 OR RuleA "5 = of=20 [[:Special:]]");
RuleD "cn,sn,telephoneNumber";
AND RuleE
AND = RuleF

My points with the above examples... 1) We can't expect = to come=20 up with
an adequate set of password quality rules and enumerate = them in=20 this
draft. 2) We need a somewhat complex syntax just to describe=20 which
rules to use.

In this example, the password quality = policy=20 rules are manageable
through LDAP, as long as the rules being used = are=20 supported by that
directory server.

Bob

, customer = envision=20 defining a way for customers to select from a
> -----Original=20 Message-----
> From: ldapext-bounces@ietf.org= =20
> [mailto:ldapext-bounces= @ietf.org]=20 On Behalf Of John McMeeking
> Sent: Monday, November 15, 2004 = 6:19=20 AM
> To: ldapext@ietf.org=20
> Subject: Re: [ldapext] Password Policy OIDs
>
> =
>=20
>
>
> I viewed my posts as describing possible = mechanisms=20 for
> extending password
> policy beyond the "basic" = password=20 policy defined in this
> draft, one using
> attributes = and=20 auxiliary classes in a schema defined by the
> extension, = this
>=20 latter providing a predefined attribute for the purpose. I
> = then drew=20 from
> other posts to form examples of how these extension =
>=20 mechanisms might be
> used, not intending that those particular = policy=20 extensions - included
> characters, excluded characters - be=20 incorporated into the
> password policy
> = document.
>=20
> In that context, debate over whether regex's should be used =
>=20 vs lists of
> characters and whether a dictionary should be in = LDAP is=20
> largely academic;
> it debate over the design of = hypothetical=20 future extensions.
> If people are
> proposing that these = be=20 added to the password policy draft,
> then it is a
> very = relevant discussion.
>
> As to manageability of features = from=20 LDAP... I guess that
> depends on where
> you want to = draw the=20 line. I agree that it is nice if you
> don't have to
> = use one=20 set of tools to manage part of the policy and another
> to = manage=20 the
> rest. On the other hand, other tools/storage mechanism may =
> be much better
> suited to managing these than LDAP. I = don't=20 think is
> necessary to store
> the dictionary in LDAP to = be able=20 to effectively manage a
> password policy
> that uses a=20 dictionary. One may want to share an existing
> dictionary = used
>=20 by other applications. Similarly, if one wanted to use
> = scripts, I=20 don't
> think the scripts need to be stored in LDAP. A file name = is=20 quite
> adequate. Alternately, the password policy parameters = could=20
> contain URLs
> referencing an LDAP entry containing a=20 dictionary or perl script.
>
> If I were designing = policies=20 dealing with dictionaries or
> scripts, I would
> = consider=20 designing the policy rule description to allow
> either to be=20 used.
> The dictionary parameter would be a URL, either a file = URL or=20
> a LDAP URL.
> Script extensions could be handled=20 similarly.
>
> So, are we talking about adding specific = new=20 policy rules to
> this document?
> Or are we talking = about how=20 password policy could be extended?
>
>
> John=20 McMeeking
>
>
> Howard Chu < hyc@highlandsun.com > = wrote on=20 11/12/2004 05:23:43 PM:
>
> > Neal-Joslin, Robert = (HP-UX Lab=20 R&D) wrote:
> > > Hi John,
> > >
> = > >=20 Yes, that is roughly it. See in-line.
> >
> > = >>Its=20 looks more to me like what Bob really was after was a
> >=20 >>policy attribute
> > >>that could be used to = describe=20 any rule -- assuming the
> > >>server = understood
> >=20 >>it.
> > >>
> > >>In that light, = maybe my=20 suggestion was a bit off the mark -
> > >>or at least = a
>=20 > >>quite different approach to the problem. I think it =
>=20 would be quite
> > >>reasonable to define a = multi-valued=20 attribute, say
> pwdPolicyRule, that
> > = >>consisted of=20 three parts:
> > >>- name for this rule = instance
> >=20 >>- OID for the rule it describes (server must implement this = rule=20 &
> > >>advertise it?)
> > >>- = parameters=20 for the rule, perhaps in some XML format - or
> > = >>maybe the=20 whole
> > >>attribute in XML.
> >
> > = In=20 general I dislike adding any feature in LDAP that is not
> = itself=20 also
> > manageable by LDAP. But it appears that there may be = no=20 other choice
> > here. For the Password Policy prototype that = Neil=20 Dunbar @
> HP wrote, he
> > added an attribute = specifying the=20 name of an external
> executable program
> > to be = used to=20 validate the password. That punts the
> problem, but you = can
>=20 > no longer view your entire policy with just an LDAP search, you=20 need
> > external knowledge.
> >
> > With = respect=20 to external dictionaries, I'd say just use
> LDAP search = URLs
>=20 > and require the dictionary to exist as an LDAP entry.
>=20 >
> > > XML would be fine, especially for readability. = And XML=20 format
> > probably should be recommended. But I like the = option of=20 leaving
> > the encoding up to the implementer. We're = assuming that=20 XML would
> > suit everyone's needs. More importantly, the I = would=20 argue that we
> > can't come up with a single DTD.
>=20 >
> > XML is ok for representing data. But when you are = talking=20 about a
> > collection of rules and behaviors, what you're = talking=20
> about is really a
> > program, and what would be = best here=20 would be a scripting
> language. perl
> > would be = well suited=20 to the task, and I'm sure there are others.
> >
> >=20 >>The attribute would use something like a "policy rule = name"
>=20 > >>matching rule -
> > >>i.e. each = pwdPolicyRule=20 value must have a unique name. This
> > >>would = allow
>=20 > >>multiple instances of a given rule OID.
> >=20 >>
> > >>A combination of required chars and = excluded=20 character
> > >>policies might look
> > = >>like=20 (pardon my XML):
> > >>
> > >># requires = 2=20 special characters, 1 from each of these sets:
> >=20 >>pwdPolicyRule: rule1 requiredchars-oid <rule count=3D"1" =
>=20 chars=3D"!@#$" />
> > >>pwdPolicyRule: rule2 = requiredchars-oid=20 <rule count=3D"1"
> chars=3D"%^&" />
> > = >>#=20 vowels not allowed
> > >>pwdPolicyRule: rule3 = excludedchars-oid=20 <rule chars=3D"aeiouAEIOU" />
> > >>
> > = >>I=20 suppose a better version might be:
> > >>pwdPolicyRule: = <excludedCharsRule name=3D"rule3"
> chars=3D"aeiouAEIOU" = />
>=20 > >>
> > >
> > > As I hinted in my = last=20 message, we may need an optional "Required
> > Rule" field. = For=20 example, let's suppose I want to encode the
> > following=20 policy...
> > >
> > > "Password must have at = least 4=20 characters and not be in a
> > dictionary. It must also = contain 3 of=20 the following: 1 upper case
> > character, 1 lower case = character, 1=20 character of '!@#$%^&*()_+=3D[]-'
> > or 1 numeric = digit.
>=20 > >
> > > To encode this, I would need a way to = specify that=20 "min 4" and
> > "not in dictionary" are required. And in = addition, I=20 would need a
> > rule that says at least 3 of the = "non-required"=20 rules must pass.
> > >
> > > Yes, this is = getting=20 ugly. And I don't want to hinder the
> > progress of the = pwd-policy=20 draft.
> >
> > --
> > -- Howard Chu
> = >=20 Chief Architect, Symas Corp. Director, Highland Sun
> > http://www.symas.com http://highlandsun.com/hyc =
>=20 > Symas: Premier OpenSource Development and Support
> = >
>=20 > _______________________________________________
> > = Ldapext=20 mailing list
> > Ldapext@ietf.org
> = > https://www1.ietf= .org/mailman/listinfo/ldapext=20
>
>
>=20 _______________________________________________
> Ldapext = mailing=20 list
> Ldapext@ietf.org=20
> https://www1.ietf= .org/mailman/listinfo/ldapext=20
> =

_______________________________________________
Ldapext=20 mailing list
Ldapext@ietf.org=20
https://www1.ietf= .org/mailman/listinfo/ldapext=20
------_=_NextPart_001_01C4DD4A.2F7763A2-- --===============0086076612== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0086076612==-- From ldapext-bounces@ietf.org Wed Dec 8 15:09:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29201 for ; Wed, 8 Dec 2004 15:09:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc7zb-0004D7-7N; Wed, 08 Dec 2004 15:00:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc7qX-0000B5-S6; Wed, 08 Dec 2004 14:51:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27755; Wed, 8 Dec 2004 14:51:32 -0500 (EST) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc7xN-00064Q-1d; Wed, 08 Dec 2004 14:58:38 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB8JoqGW004036; Wed, 8 Dec 2004 14:50:52 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB8Joq1m242892; Wed, 8 Dec 2004 14:50:52 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB8JopC0030141; Wed, 8 Dec 2004 14:50:51 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.229.77]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB8JopPP030071; Wed, 8 Dec 2004 14:50:51 -0500 In-Reply-To: <632116003944094FB495E72A6EDB90B281AC2E@cacexc10.americas.cpqcorp.net> Subject: RE: [ldapext] Password Policy OIDs To: "Neal-Joslin, Robert (HP-UX Lab R&D)" X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: John McMeeking Date: Wed, 8 Dec 2004 13:50:47 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V70_M3_11102004|November 10, 2004) at 12/08/2004 01:50:51 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e9d8c60d9288f2c774f26bab15869505 Cc: Duane Buss , ldapext-bounces@ietf.org, ldapext@ietf.org, Tammy Green , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org You asked if the "# of" expression is valuable? I don't know. The few groups I've dealt with don't have rules as complex as "satisfy 3 of 4 rules plus the following" unless you were going to try to express "must have n letters + at least of the following: number, special character, mixed case letters" in that way. I would hope that rule can be expressed as a single rule, not "rule1 AND 1 of {rule2, rule3, rule4}" Like Jim, I expected that an AND of all rules would be sufficient. I know I'd hate to be the user trying to figure out what passwords I'll be able to use. If password policy uses something like either your syntax or the AND/OR/... suggestion from Jim, I suggest that we try to keep the rules (and their arguments) separate from the specification of which rules must be satisfied. I'm not feeling very inventive for attribute names, but I'd hope it would be something like: pwdPolicySubrule: Rinc inclusion-policy-oid pwdPolicySubrule: RdictA dictionary-policy-oid pwdPolicySubrule: RdictB dictionary-policy-oid pwdPolicySubrule: Rmin3 minlength-policy-oid ..... pwdPolicyRule: 3 of (Rinc, RdictA, RdictB) AND Ryear AND Rmon [I know I slaughtered your example, but...] That is: - pwdPolicyRule can be expressed using just rule names and logical expressions - pwdPolicySubrules specify the details of each subrule (name of the rule instance, OID of the particular policy, and arguments) That allows individual policies to be mixed and matched, or plugged in, while having a managable overall policy enforcement that only needs to know if a given password satifies each sub rule without getting bogged down in the details of a given rule. John McMeeking "Neal-Joslin, Robert (HP-UX Lab R&D)" wrote on 12/08/2004 11:20:16 AM: > Hi Jim, > > Thanks for the reply. > > I did consider using combinations of rules, to help simplify the > logic syntax. And I would be happy with it too. But the two main > reasons I proposed the "# of" syntax is... First, the number of > combinations grow exponentially. Second, when you have to specify > arguments to the rule, you need to re-specify a perhaps large set of > the same arguments over and over (I need some clarifications on how > you propose passing arguments into rules. See below.) > > I think the real question is, is the "# of" expression valuable? I > know of a couple of customers that depend on it for password quality > checking. But does that mean we need it? Should LDAP directory > servers provide the ultimate password quality checking semantics? > > On the second point, I'd like to clarify the question I have above > about arguments to rules. You said "The specification for any given > rule would define mechanisms for the storage of rule-related data." > This sounds like something I was proposing earlier, that each rule > would need to have it's own set of arguments that it would > interpret. This argument list would be a specified within the rule > syntax, but would be a data blob. And that no elements within the > argument data blob would need to be specified or interpreted by the > syntax. Correct? I assume that when you specified the example > below, that P1 represents rule1 along with the arguments to rule1. > > To me I think it's necessary to have the ability to specify > arguments to the rules within the pwdQualityRules attribute. For > example, suppose we have the "Minimum number of characters" rule. > It seems that an argument is required to specify what specific > number of characters is the minimum. I suppose it's possible to > specify that argument elsewhere, perhaps in a configuration file > that the is known to the rule. But that would make it harder to > specify a rule set such as "Password must contain at least 10 > characters, or be at least 7 characters long and contain a special character." > > Thanks > > Bob > > > > From: Jim Sermersheim [mailto:jimse@novell.com] > Sent: Wednesday, December 08, 2004 6:05 AM > To: Neal-Joslin, Robert (HP-UX Lab R&D); jmcmeek@us.ibm.com > Cc: ldapext@ietf.org; Duane Buss; Tammy Green > Subject: RE: [ldapext] Password Policy OIDs > In general I agree with this approach. For a while I've been > thinking that an OID-syntax multi-valued attribute would be > sufficient (where each OID represents a rule specified somewhere), > and that all rules would always be ANDed (rule specifications could > talk more about the semantics of the combinations of certain rules). > The specification for any given rule would define mechanisms for the > storage of rule-related data (i.e. a dictionary rule might specify > that some pwdDictionary attribute be used to hold values like "! > (substr(3) dictA)". That way, the list of rules is kept as simple aspossible. > > However, I can see that allowing ORs (and possibly other) operators > would be useful. > I know a simple syntax allowing AND and OR is not as flexible as > what you've described below (where you have "3 of"), but is it > sufficient? If we call your criteria below P1 - P6, using only AND > and OR we'd have to do this: > ( (P1 AND P2 AND P3) > OR (P1 AND P2 AND P4) > OR (P1 AND P3 AND P4) > OR (P2 AND P3 AND P4) > ) > AND P5 > AND P6 > > Jim > > >>> "Neal-Joslin, Robert (HP-UX Lab R&D)" > 12/6/04 11:10:02 AM >>> > Hi John, > > My apologies for a delayed reply. I've been extremely busy, but would > still like to follow up. > > I would just like to follow up on your last question. Are we proposing > standard policy rules or a method for extending, and possibly managing, > password policy rules? IMHO, we could define a specific set of password > policy rules. However, we can not expect that that set of rules would > be adequate for a typical deployment. Therefore we need to look at way > to allow for extension of password policies. > > I personally feel that the draft should include a way for customers to > define the rules they require for password quality checking, doing so > out of a collection of rules. Those rules can be defined by standards > bodies, vendors of directory products, third parties or end customers. > All we really need is a syntax that allows the directory administrator > to select from that set. As an example, I think the syntax should allow > the expression of something like the following. > > Newly created passwords must, follow 3 of the following 4 > requirements: > > 1) Contain at least one alpha or numeric character > 2) Not contain a substring of 3 or more characters that matches > a word found in either dictionary A or in dictionary B > 3) Be at least 7 characters in length or contain at least 5 special > characters. > 4) Not contain either the cn, sn or telephone number attributes. > > And the newly created password must > > 5) Not be constructed using current year, represented numerically. > 6) Not be constructed using the current month, represented either as > 2 digits or as a substring of 3 or more characters of the name > of the month > > To clarify, my proposal is not that the draft be able to express the > details of those rules, just which rules in which combination. I could > re-state it as the following... > > RuleA = Character inclusion > RuleB = Dictionary substring exclusion > RuleC = Min length > RuleD = Attribute substring exclusion > RuleE = Current year exclusion > RuleF = Current month exclusion > > Where the syntax might look more like (but not exactly like) > > Choose 3 OF > RuleA "1 of [A-Z,a-z,0-9]"; > (RuleB "Dictionary A min 3" AND > RuleB "Dictionary B min 3"); > (RuleC 7 OR RuleA "5 of [[:Special:]]"); > RuleD "cn,sn,telephoneNumber"; > AND RuleE > AND RuleF > > My points with the above examples... 1) We can't expect to come up with > an adequate set of password quality rules and enumerate them in this > draft. 2) We need a somewhat complex syntax just to describe which > rules to use. > > In this example, the password quality policy rules are manageable > through LDAP, as long as the rules being used are supported by that > directory server. > > Bob > > , customer envision defining a way for customers to select from a > > -----Original Message----- > > From: ldapext-bounces@ietf.org > > [mailto:ldapext-bounces@ietf.org] On Behalf Of John McMeeking > > Sent: Monday, November 15, 2004 6:19 AM > > To: ldapext@ietf.org > > Subject: Re: [ldapext] Password Policy OIDs > > > > > > > > > > > > I viewed my posts as describing possible mechanisms for > > extending password > > policy beyond the "basic" password policy defined in this > > draft, one using > > attributes and auxiliary classes in a schema defined by the > > extension, this > > latter providing a predefined attribute for the purpose. I > > then drew from > > other posts to form examples of how these extension > > mechanisms might be > > used, not intending that those particular policy extensions - included > > characters, excluded characters - be incorporated into the > > password policy > > document. > > > > In that context, debate over whether regex's should be used > > vs lists of > > characters and whether a dictionary should be in LDAP is > > largely academic; > > it debate over the design of hypothetical future extensions. > > If people are > > proposing that these be added to the password policy draft, > > then it is a > > very relevant discussion. > > > > As to manageability of features from LDAP... I guess that > > depends on where > > you want to draw the line. I agree that it is nice if you > > don't have to > > use one set of tools to manage part of the policy and another > > to manage the > > rest. On the other hand, other tools/storage mechanism may > > be much better > > suited to managing these than LDAP. I don't think is > > necessary to store > > the dictionary in LDAP to be able to effectively manage a > > password policy > > that uses a dictionary. One may want to share an existing > > dictionary used > > by other applications. Similarly, if one wanted to use > > scripts, I don't > > think the scripts need to be stored in LDAP. A file name is quite > > adequate. Alternately, the password policy parameters could > > contain URLs > > referencing an LDAP entry containing a dictionary or perl script. > > > > If I were designing policies dealing with dictionaries or > > scripts, I would > > consider designing the policy rule description to allow > > either to be used. > > The dictionary parameter would be a URL, either a file URL or > > a LDAP URL. > > Script extensions could be handled similarly. > > > > So, are we talking about adding specific new policy rules to > > this document? > > Or are we talking about how password policy could be extended? > > > > > > John McMeeking > > > > > > Howard Chu < hyc@highlandsun.com > wrote on 11/12/2004 05:23:43 PM: > > > > > Neal-Joslin, Robert (HP-UX Lab R&D) wrote: > > > > Hi John, > > > > > > > > Yes, that is roughly it. See in-line. > > > > > > >>Its looks more to me like what Bob really was after was a > > > >>policy attribute > > > >>that could be used to describe any rule -- assuming the > > > >>server understood > > > >>it. > > > >> > > > >>In that light, maybe my suggestion was a bit off the mark - > > > >>or at least a > > > >>quite different approach to the problem. I think it > > would be quite > > > >>reasonable to define a multi-valued attribute, say > > pwdPolicyRule, that > > > >>consisted of three parts: > > > >>- name for this rule instance > > > >>- OID for the rule it describes (server must implement this rule & > > > >>advertise it?) > > > >>- parameters for the rule, perhaps in some XML format - or > > > >>maybe the whole > > > >>attribute in XML. > > > > > > In general I dislike adding any feature in LDAP that is not > > itself also > > > manageable by LDAP. But it appears that there may be no other choice > > > here. For the Password Policy prototype that Neil Dunbar @ > > HP wrote, he > > > added an attribute specifying the name of an external > > executable program > > > to be used to validate the password. That punts the > > problem, but you can > > > no longer view your entire policy with just an LDAP search, you need > > > external knowledge. > > > > > > With respect to external dictionaries, I'd say just use > > LDAP search URLs > > > and require the dictionary to exist as an LDAP entry. > > > > > > > XML would be fine, especially for readability. And XML format > > > probably should be recommended. But I like the option of leaving > > > the encoding up to the implementer. We're assuming that XML would > > > suit everyone's needs. More importantly, the I would argue that we > > > can't come up with a single DTD. > > > > > > XML is ok for representing data. But when you are talking about a > > > collection of rules and behaviors, what you're talking > > about is really a > > > program, and what would be best here would be a scripting > > language. perl > > > would be well suited to the task, and I'm sure there are others. > > > > > > >>The attribute would use something like a "policy rule name" > > > >>matching rule - > > > >>i.e. each pwdPolicyRule value must have a unique name. This > > > >>would allow > > > >>multiple instances of a given rule OID. > > > >> > > > >>A combination of required chars and excluded character > > > >>policies might look > > > >>like (pardon my XML): > > > >> > > > >># requires 2 special characters, 1 from each of these sets: > > > >>pwdPolicyRule: rule1 requiredchars-oid > chars="!@#$" /> > > > >>pwdPolicyRule: rule2 requiredchars-oid > chars="%^&" /> > > > >># vowels not allowed > > > >>pwdPolicyRule: rule3 excludedchars-oid > > > >> > > > >>I suppose a better version might be: > > > >>pwdPolicyRule: > chars="aeiouAEIOU" /> > > > >> > > > > > > > > As I hinted in my last message, we may need an optional "Required > > > Rule" field. For example, let's suppose I want to encode the > > > following policy... > > > > > > > > "Password must have at least 4 characters and not be in a > > > dictionary. It must also contain 3 of the following: 1 upper case > > > character, 1 lower case character, 1 character of '!@#$%^&*()_+=[]-' > > > or 1 numeric digit. > > > > > > > > To encode this, I would need a way to specify that "min 4" and > > > "not in dictionary" are required. And in addition, I would need a > > > rule that says at least 3 of the "non-required" rules must pass. > > > > > > > > Yes, this is getting ugly. And I don't want to hinder the > > > progress of the pwd-policy draft. > > > > > > -- > > > -- Howard Chu > > > Chief Architect, Symas Corp. Director, Highland Sun > > > http://www.symas.com http://highlandsun.com/hyc > > > Symas: Premier OpenSource Development and Support > > > > > > _______________________________________________ > > > Ldapext mailing list > > > Ldapext@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ldapext > > > > > > _______________________________________________ > > Ldapext mailing list > > Ldapext@ietf.org > > https://www1.ietf.org/mailman/listinfo/ldapext > > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Dec 8 15:22:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00986 for ; Wed, 8 Dec 2004 15:22:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc87x-0003Fv-Cn; Wed, 08 Dec 2004 15:09:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc7zh-0004Ky-FN; Wed, 08 Dec 2004 15:01:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28507; Wed, 8 Dec 2004 15:00:59 -0500 (EST) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc86W-0006Ia-9h; Wed, 08 Dec 2004 15:08:05 -0500 Received: from cacexg11.americas.cpqcorp.net (cacexg11.americas.cpqcorp.net [16.92.1.67]) by palrel11.hp.com (Postfix) with ESMTP id 93659301D0; Wed, 8 Dec 2004 12:00:57 -0800 (PST) Received: from cacexc10.americas.cpqcorp.net ([16.92.1.47]) by cacexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Dec 2004 12:00:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] Password Policy OIDs Date: Wed, 8 Dec 2004 12:00:55 -0800 Message-ID: <632116003944094FB495E72A6EDB90B281ACE9@cacexc10.americas.cpqcorp.net> Thread-Topic: [ldapext] Password Policy OIDs Thread-Index: AcTdXz7mA0bpbmMSTIWaswsxhBIN/gAAH7EA From: "Neal-Joslin, Robert (HP-UX Lab R&D)" To: "John McMeeking" X-OriginalArrivalTime: 08 Dec 2004 20:00:57.0408 (UTC) FILETIME=[A1C86400:01C4DD60] X-Spam-Score: 0.0 (/) X-Scan-Signature: c375f2012a4f820b0c0fd6fb14a28357 Content-Transfer-Encoding: quoted-printable Cc: Duane Buss , ldapext-bounces@ietf.org, ldapext@ietf.org, Tammy Green , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi John, I thought about separating the rule specification from the rule usage (as you show below.) But there is some limitation in that if you want to specify a rule such as in my previous example to Jim, ("password must be at least 10 characters long or at least 7 characters long with 1 special character") you need a way to extend the specification of the rules since one rule is used twice with different options. I suppose that's not required if you eliminate the OR directive. But I think it needs to be brought up. Bob =20 > -----Original Message----- > From: John McMeeking [mailto:jmcmeek@us.ibm.com]=20 > Sent: Wednesday, December 08, 2004 11:51 AM > To: Neal-Joslin, Robert (HP-UX Lab R&D) > Cc: Duane Buss; Jim Sermersheim; ldapext@ietf.org;=20 > ldapext-bounces@ietf.org; Tammy Green > Subject: RE: [ldapext] Password Policy OIDs >=20 >=20 >=20 >=20 >=20 > You asked if the "# of" expression is valuable? I don't=20 > know. The few > groups I've dealt with don't have rules as complex as=20 > "satisfy 3 of 4 rules > plus the following" unless you were going to try to express=20 > "must have n > letters + at least of the following: number, special=20 > character, mixed case > letters" in that way. I would hope that rule can be=20 > expressed as a single > rule, not "rule1 AND 1 of {rule2, rule3, rule4}" >=20 > Like Jim, I expected that an AND of all rules would be=20 > sufficient. I know > I'd hate to be the user trying to figure out what passwords=20 > I'll be able to > use. >=20 > If password policy uses something like either your syntax or=20 > the AND/OR/... > suggestion from Jim, I suggest that we try to keep the rules=20 > (and their > arguments) separate from the specification of which rules must be > satisfied. I'm not feeling very inventive for attribute=20 > names, but I'd > hope it would be something like: >=20 > pwdPolicySubrule: Rinc inclusion-policy-oid A-Z,a-z,0-9 > > pwdPolicySubrule: RdictA dictionary-policy-oid dictionary A > > pwdPolicySubrule: RdictB dictionary-policy-oid dictionary B > > pwdPolicySubrule: Rmin3 minlength-policy-oid least 3 chars> > ..... > pwdPolicyRule: 3 of (Rinc, RdictA, RdictB) AND Ryear AND Rmon > [I know I slaughtered your example, but...] >=20 > That is: > - pwdPolicyRule can be expressed using just rule names and logical > expressions > - pwdPolicySubrules specify the details of each subrule (name=20 > of the rule > instance, OID of the particular policy, and arguments) >=20 > That allows individual policies to be mixed and matched, or=20 > plugged in, > while having a managable overall policy enforcement that only=20 > needs to know > if a given password satifies each sub rule without getting=20 > bogged down in > the details of a given rule. >=20 >=20 > John McMeeking >=20 >=20 > "Neal-Joslin, Robert (HP-UX Lab R&D)" wrote on > 12/08/2004 11:20:16 AM: >=20 > > Hi Jim, > > > > Thanks for the reply. > > > > I did consider using combinations of rules, to help simplify the > > logic syntax. And I would be happy with it too. But the two main > > reasons I proposed the "# of" syntax is... First, the number of > > combinations grow exponentially. Second, when you have to specify > > arguments to the rule, you need to re-specify a perhaps large set of > > the same arguments over and over (I need some clarifications on how > > you propose passing arguments into rules. See below.) > > > > I think the real question is, is the "# of" expression valuable? I > > know of a couple of customers that depend on it for password quality > > checking. But does that mean we need it? Should LDAP directory > > servers provide the ultimate password quality checking semantics? > > > > On the second point, I'd like to clarify the question I have above > > about arguments to rules. You said "The specification for any given > > rule would define mechanisms for the storage of rule-related data." > > This sounds like something I was proposing earlier, that each rule > > would need to have it's own set of arguments that it would > > interpret. This argument list would be a specified within the rule > > syntax, but would be a data blob. And that no elements within the > > argument data blob would need to be specified or interpreted by the > > syntax. Correct? I assume that when you specified the example > > below, that P1 represents rule1 along with the arguments to rule1. > > > > To me I think it's necessary to have the ability to specify > > arguments to the rules within the pwdQualityRules attribute. For > > example, suppose we have the "Minimum number of characters" rule. > > It seems that an argument is required to specify what specific > > number of characters is the minimum. I suppose it's possible to > > specify that argument elsewhere, perhaps in a configuration file > > that the is known to the rule. But that would make it harder to > > specify a rule set such as "Password must contain at least 10 > > characters, or be at least 7 characters long and contain a special > character." > > > > Thanks > > > > Bob > > > > > > > > From: Jim Sermersheim [mailto:jimse@novell.com] > > Sent: Wednesday, December 08, 2004 6:05 AM > > To: Neal-Joslin, Robert (HP-UX Lab R&D); jmcmeek@us.ibm.com > > Cc: ldapext@ietf.org; Duane Buss; Tammy Green > > Subject: RE: [ldapext] Password Policy OIDs >=20 > > In general I agree with this approach. For a while I've been > > thinking that an OID-syntax multi-valued attribute would be > > sufficient (where each OID represents a rule specified somewhere), > > and that all rules would always be ANDed (rule specifications could > > talk more about the semantics of the combinations of certain rules). > > The specification for any given rule would define mechanisms for the > > storage of rule-related data (i.e. a dictionary rule might specify > > that some pwdDictionary attribute be used to hold values like "! > > (substr(3) dictA)". That way, the list of rules is kept as simple > aspossible. > > > > However, I can see that allowing ORs (and possibly other) operators > > would be useful. > > I know a simple syntax allowing AND and OR is not as flexible as > > what you've described below (where you have "3 of"), but is it > > sufficient? If we call your criteria below P1 - P6, using only AND > > and OR we'd have to do this: > > ( (P1 AND P2 AND P3) > > OR (P1 AND P2 AND P4) > > OR (P1 AND P3 AND P4) > > OR (P2 AND P3 AND P4) > > ) > > AND P5 > > AND P6 > > > > Jim > > > > >>> "Neal-Joslin, Robert (HP-UX Lab R&D)" > > 12/6/04 11:10:02 AM >>> > > Hi John, > > > > My apologies for a delayed reply. I've been extremely busy,=20 > but would > > still like to follow up. > > > > I would just like to follow up on your last question. Are=20 > we proposing > > standard policy rules or a method for extending, and=20 > possibly managing, > > password policy rules? IMHO, we could define a specific set=20 > of password > > policy rules. However, we can not expect that that set of=20 > rules would > > be adequate for a typical deployment. Therefore we need to=20 > look at way > > to allow for extension of password policies. > > > > I personally feel that the draft should include a way for=20 > customers to > > define the rules they require for password quality=20 > checking, doing so > > out of a collection of rules. Those rules can be defined by=20 > standards > > bodies, vendors of directory products, third parties or end=20 > customers. > > All we really need is a syntax that allows the directory=20 > administrator > > to select from that set. As an example, I think the syntax=20 > should allow > > the expression of something like the following. > > > > Newly created passwords must, follow 3 of the following 4 > > requirements: > > > > 1) Contain at least one alpha or numeric character > > 2) Not contain a substring of 3 or more characters that matches > > a word found in either dictionary A or in dictionary B > > 3) Be at least 7 characters in length or contain at least 5 special > > characters. > > 4) Not contain either the cn, sn or telephone number attributes. > > > > And the newly created password must > > > > 5) Not be constructed using current year, represented numerically. > > 6) Not be constructed using the current month, represented either as > > 2 digits or as a substring of 3 or more characters of the name > > of the month > > > > To clarify, my proposal is not that the draft be able to express the > > details of those rules, just which rules in which=20 > combination. I could > > re-state it as the following... > > > > RuleA =3D Character inclusion > > RuleB =3D Dictionary substring exclusion > > RuleC =3D Min length > > RuleD =3D Attribute substring exclusion > > RuleE =3D Current year exclusion > > RuleF =3D Current month exclusion > > > > Where the syntax might look more like (but not exactly like) > > > > Choose 3 OF > > RuleA "1 of [A-Z,a-z,0-9]"; > > (RuleB "Dictionary A min 3" AND > > RuleB "Dictionary B min 3"); > > (RuleC 7 OR RuleA "5 of [[:Special:]]"); > > RuleD "cn,sn,telephoneNumber"; > > AND RuleE > > AND RuleF > > > > My points with the above examples... 1) We can't expect to=20 > come up with > > an adequate set of password quality rules and enumerate them in this > > draft. 2) We need a somewhat complex syntax just to describe which > > rules to use. > > > > In this example, the password quality policy rules are manageable > > through LDAP, as long as the rules being used are supported by that > > directory server. > > > > Bob > > > > , customer envision defining a way for customers to select from a > > > -----Original Message----- > > > From: ldapext-bounces@ietf.org > > > [mailto:ldapext-bounces@ietf.org] On Behalf Of John McMeeking > > > Sent: Monday, November 15, 2004 6:19 AM > > > To: ldapext@ietf.org > > > Subject: Re: [ldapext] Password Policy OIDs > > > > > > > > > > > > > > > > > > I viewed my posts as describing possible mechanisms for > > > extending password > > > policy beyond the "basic" password policy defined in this > > > draft, one using > > > attributes and auxiliary classes in a schema defined by the > > > extension, this > > > latter providing a predefined attribute for the purpose. I > > > then drew from > > > other posts to form examples of how these extension > > > mechanisms might be > > > used, not intending that those particular policy=20 > extensions - included > > > characters, excluded characters - be incorporated into the > > > password policy > > > document. > > > > > > In that context, debate over whether regex's should be used > > > vs lists of > > > characters and whether a dictionary should be in LDAP is > > > largely academic; > > > it debate over the design of hypothetical future extensions. > > > If people are > > > proposing that these be added to the password policy draft, > > > then it is a > > > very relevant discussion. > > > > > > As to manageability of features from LDAP... I guess that > > > depends on where > > > you want to draw the line. I agree that it is nice if you > > > don't have to > > > use one set of tools to manage part of the policy and another > > > to manage the > > > rest. On the other hand, other tools/storage mechanism may > > > be much better > > > suited to managing these than LDAP. I don't think is > > > necessary to store > > > the dictionary in LDAP to be able to effectively manage a > > > password policy > > > that uses a dictionary. One may want to share an existing > > > dictionary used > > > by other applications. Similarly, if one wanted to use > > > scripts, I don't > > > think the scripts need to be stored in LDAP. A file name is quite > > > adequate. Alternately, the password policy parameters could > > > contain URLs > > > referencing an LDAP entry containing a dictionary or perl script. > > > > > > If I were designing policies dealing with dictionaries or > > > scripts, I would > > > consider designing the policy rule description to allow > > > either to be used. > > > The dictionary parameter would be a URL, either a file URL or > > > a LDAP URL. > > > Script extensions could be handled similarly. > > > > > > So, are we talking about adding specific new policy rules to > > > this document? > > > Or are we talking about how password policy could be extended? > > > > > > > > > John McMeeking > > > > > > > > > Howard Chu < hyc@highlandsun.com > wrote on 11/12/2004=20 > 05:23:43 PM: > > > > > > > Neal-Joslin, Robert (HP-UX Lab R&D) wrote: > > > > > Hi John, > > > > > > > > > > Yes, that is roughly it. See in-line. > > > > > > > > >>Its looks more to me like what Bob really was after was a > > > > >>policy attribute > > > > >>that could be used to describe any rule -- assuming the > > > > >>server understood > > > > >>it. > > > > >> > > > > >>In that light, maybe my suggestion was a bit off the mark - > > > > >>or at least a > > > > >>quite different approach to the problem. I think it > > > would be quite > > > > >>reasonable to define a multi-valued attribute, say > > > pwdPolicyRule, that > > > > >>consisted of three parts: > > > > >>- name for this rule instance > > > > >>- OID for the rule it describes (server must=20 > implement this rule & > > > > >>advertise it?) > > > > >>- parameters for the rule, perhaps in some XML format - or > > > > >>maybe the whole > > > > >>attribute in XML. > > > > > > > > In general I dislike adding any feature in LDAP that is not > > > itself also > > > > manageable by LDAP. But it appears that there may be no=20 > other choice > > > > here. For the Password Policy prototype that Neil Dunbar @ > > > HP wrote, he > > > > added an attribute specifying the name of an external > > > executable program > > > > to be used to validate the password. That punts the > > > problem, but you can > > > > no longer view your entire policy with just an LDAP=20 > search, you need > > > > external knowledge. > > > > > > > > With respect to external dictionaries, I'd say just use > > > LDAP search URLs > > > > and require the dictionary to exist as an LDAP entry. > > > > > > > > > XML would be fine, especially for readability. And XML format > > > > probably should be recommended. But I like the option of leaving > > > > the encoding up to the implementer. We're assuming that=20 > XML would > > > > suit everyone's needs. More importantly, the I would=20 > argue that we > > > > can't come up with a single DTD. > > > > > > > > XML is ok for representing data. But when you are=20 > talking about a > > > > collection of rules and behaviors, what you're talking > > > about is really a > > > > program, and what would be best here would be a scripting > > > language. perl > > > > would be well suited to the task, and I'm sure there are others. > > > > > > > > >>The attribute would use something like a "policy rule name" > > > > >>matching rule - > > > > >>i.e. each pwdPolicyRule value must have a unique name. This > > > > >>would allow > > > > >>multiple instances of a given rule OID. > > > > >> > > > > >>A combination of required chars and excluded character > > > > >>policies might look > > > > >>like (pardon my XML): > > > > >> > > > > >># requires 2 special characters, 1 from each of these sets: > > > > >>pwdPolicyRule: rule1 requiredchars-oid > > chars=3D"!@#$" /> > > > > >>pwdPolicyRule: rule2 requiredchars-oid > > chars=3D"%^&" /> > > > > >># vowels not allowed > > > > >>pwdPolicyRule: rule3 excludedchars-oid chars=3D"aeiouAEIOU" /> > > > > >> > > > > >>I suppose a better version might be: > > > > >>pwdPolicyRule: > > chars=3D"aeiouAEIOU" /> > > > > >> > > > > > > > > > > As I hinted in my last message, we may need an=20 > optional "Required > > > > Rule" field. For example, let's suppose I want to encode the > > > > following policy... > > > > > > > > > > "Password must have at least 4 characters and not be in a > > > > dictionary. It must also contain 3 of the following: 1=20 > upper case > > > > character, 1 lower case character, 1 character of=20 > '!@#$%^&*()_+=3D[]-' > > > > or 1 numeric digit. > > > > > > > > > > To encode this, I would need a way to specify that "min 4" and > > > > "not in dictionary" are required. And in addition, I=20 > would need a > > > > rule that says at least 3 of the "non-required" rules must pass. > > > > > > > > > > Yes, this is getting ugly. And I don't want to hinder the > > > > progress of the pwd-policy draft. > > > > > > > > -- > > > > -- Howard Chu > > > > Chief Architect, Symas Corp. Director, Highland Sun > > > > http://www.symas.com http://highlandsun.com/hyc > > > > Symas: Premier OpenSource Development and Support > > > > > > > > _______________________________________________ > > > > Ldapext mailing list > > > > Ldapext@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ldapext > > > > > > > > > _______________________________________________ > > > Ldapext mailing list > > > Ldapext@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ldapext > > > > > > > _______________________________________________ > > Ldapext mailing list > > Ldapext@ietf.org > > https://www1.ietf.org/mailman/listinfo/ldapext > > _______________________________________________ > > Ldapext mailing list > > Ldapext@ietf.org > > https://www1.ietf.org/mailman/listinfo/ldapext >=20 >=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Dec 8 15:37:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02024 for ; Wed, 8 Dec 2004 15:37:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc8Me-0003w8-Gv; Wed, 08 Dec 2004 15:24:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc8HO-0008P9-BJ; Wed, 08 Dec 2004 15:19:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00655; Wed, 8 Dec 2004 15:19:16 -0500 (EST) Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc8OE-0006eD-AE; Wed, 08 Dec 2004 15:26:22 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.12.9/8.12.9) with ESMTP id iB8KIw96012947; Wed, 8 Dec 2004 14:18:58 -0600 Message-ID: <41B761C9.6090705@highlandsun.com> Date: Wed, 08 Dec 2004 12:19:21 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John McMeeking Subject: Re: [ldapext] Password Policy OIDs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: Duane Buss , ldapext-bounces@ietf.org, "Neal-Joslin, Robert \(HP-UX Lab R&D\)" , Tammy Green , ldapext@ietf.org, Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit John McMeeking wrote: > > > > You asked if the "# of" expression is valuable? I don't know. The few > groups I've dealt with don't have rules as complex as "satisfy 3 of 4 rules > plus the following" unless you were going to try to express "must have n > letters + at least of the following: number, special character, mixed case > letters" in that way. I would hope that rule can be expressed as a single > rule, not "rule1 AND 1 of {rule2, rule3, rule4}" > > Like Jim, I expected that an AND of all rules would be sufficient. I know > I'd hate to be the user trying to figure out what passwords I'll be able to > use. > > If password policy uses something like either your syntax or the AND/OR/... > suggestion from Jim, I suggest that we try to keep the rules (and their > arguments) separate from the specification of which rules must be > satisfied. I'm not feeling very inventive for attribute names, but I'd > hope it would be something like: Yes, I think it would be smart to separate the rule specification from this point, so as not to slow things down here any further. Although I'll reiterate that if you want to express rules that are applied sequentially and conditionally, you're talking about a program and a programming language. And I think it is wrong to invent a new programming language here. Also, we *are* talking about sequential and conditional application of rules; simple Boolean combinations of a static set of rules is going to drive everyone crazy. As Robert already said, the combinations grow exponentially. > > pwdPolicySubrule: Rinc inclusion-policy-oid A-Z,a-z,0-9 > > pwdPolicySubrule: RdictA dictionary-policy-oid dictionary A > > pwdPolicySubrule: RdictB dictionary-policy-oid dictionary B > > pwdPolicySubrule: Rmin3 minlength-policy-oid least 3 chars> > ..... > pwdPolicyRule: 3 of (Rinc, RdictA, RdictB) AND Ryear AND Rmon > [I know I slaughtered your example, but...] > > That is: > - pwdPolicyRule can be expressed using just rule names and logical > expressions > - pwdPolicySubrules specify the details of each subrule (name of the rule > instance, OID of the particular policy, and arguments) > > That allows individual policies to be mixed and matched, or plugged in, > while having a managable overall policy enforcement that only needs to know > if a given password satifies each sub rule without getting bogged down in > the details of a given rule. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Dec 8 16:52:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09620 for ; Wed, 8 Dec 2004 16:52:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc9Mi-0002Vs-Gn; Wed, 08 Dec 2004 16:28:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc9Cq-0007VG-4M; Wed, 08 Dec 2004 16:18:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04313; Wed, 8 Dec 2004 16:18:37 -0500 (EST) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc9Jd-0007oT-W3; Wed, 08 Dec 2004 16:25:44 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB8LHsBX006749; Wed, 8 Dec 2004 16:17:54 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB8LHreZ271482; Wed, 8 Dec 2004 16:17:53 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB8LHoA0009783; Wed, 8 Dec 2004 16:17:50 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.229.77]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB8LHo3s009737; Wed, 8 Dec 2004 16:17:50 -0500 In-Reply-To: <632116003944094FB495E72A6EDB90B281ACE9@cacexc10.americas.cpqcorp.net> Subject: RE: [ldapext] Password Policy OIDs To: "Neal-Joslin, Robert (HP-UX Lab R&D)" X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: John McMeeking Date: Wed, 8 Dec 2004 15:17:51 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V70_M3_11102004|November 10, 2004) at 12/08/2004 03:17:50 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 19c92f723dac1bcdd68591cc46e38e95 Cc: Duane Buss , ldapext-bounces@ietf.org, ldapext@ietf.org, Tammy Green , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org "Neal-Joslin, Robert (HP-UX Lab R&D)" wrote on 12/08/2004 02:00:55 PM: > Hi John, > > I thought about separating the rule specification from the rule usage > (as you show below.) But there is some limitation in that if you want > to specify a rule such as in my previous example to Jim, ("password must > be at least 10 characters long or at least 7 characters long with 1 > special character") you need a way to extend the specification of the > rules since one rule is used twice with different options. I suppose > that's not required if you eliminate the OR directive. But I think it > needs to be brought up. There's a few ways to approach that, but I think it comes down to how complex a particular policy is. For example, if I wanted to combine that rule with a separate rule, password not in dictionary A, I could have: 1) complex policy that directly expresses some choices # define individual pieces: pwdpolicysubrule: rule1 complex-policy-oid (length>10)||((length>7)&&(contains(!@#$%^&*))) pwdpolicysubrule: rule2 dictionary-policy-oid file:///dictionaries/password.dict # password must satify both of the above: pwdpolicyrule: rule1 AND rule2 2) several simple policies: pwdpolicysubrule: rule1 length-policy-oid minlength=10 pwdpolicysubrule: rule2 length-policy-oid minlength=7 pwdpolicysubrule: rule3 character-policy-oid contains 1 of "!@#$%^&*" pwdpolicysubrule: rule4 dictionary-policy-oid file:///dictionaries/password.dict # password must satify combinations of the above simpler rules pwdpolicyrule: (rule1 OR (rule2 AND rule3)) AND rule4 My point was that by separating the definition of pieces from the combinations that must be satified is that I can then have servers with well encapsulated and extendable policies: - a set of extendable functions to evaluate: rule1(newpassword) = TRUE rule2(newpassword) = TRUE rule3(newpassword) = FALSE rule4(newpassword) = TRUE - an engine to evalute ((rule1 OR (rule2 ...) that only needs to know the individual TRUE/FALSE results. And the syntax for expressing the combinations of rules to be satisfied need not get bogged down in providing a means for embedding the parameters for each rule. > > Bob > > > > -----Original Message----- > > From: John McMeeking [mailto:jmcmeek@us.ibm.com] > > Sent: Wednesday, December 08, 2004 11:51 AM > > To: Neal-Joslin, Robert (HP-UX Lab R&D) > > Cc: Duane Buss; Jim Sermersheim; ldapext@ietf.org; > > ldapext-bounces@ietf.org; Tammy Green > > Subject: RE: [ldapext] Password Policy OIDs > > > > > > > > > > > > You asked if the "# of" expression is valuable? I don't > > know. The few > > groups I've dealt with don't have rules as complex as > > "satisfy 3 of 4 rules > > plus the following" unless you were going to try to express > > "must have n > > letters + at least of the following: number, special > > character, mixed case > > letters" in that way. I would hope that rule can be > > expressed as a single > > rule, not "rule1 AND 1 of {rule2, rule3, rule4}" > > > > Like Jim, I expected that an AND of all rules would be > > sufficient. I know > > I'd hate to be the user trying to figure out what passwords > > I'll be able to > > use. > > > > If password policy uses something like either your syntax or > > the AND/OR/... > > suggestion from Jim, I suggest that we try to keep the rules > > (and their > > arguments) separate from the specification of which rules must be > > satisfied. I'm not feeling very inventive for attribute > > names, but I'd > > hope it would be something like: > > > > pwdPolicySubrule: Rinc inclusion-policy-oid > A-Z,a-z,0-9 > > > pwdPolicySubrule: RdictA dictionary-policy-oid > dictionary A > > > pwdPolicySubrule: RdictB dictionary-policy-oid > dictionary B > > > pwdPolicySubrule: Rmin3 minlength-policy-oid > least 3 chars> > > ..... > > pwdPolicyRule: 3 of (Rinc, RdictA, RdictB) AND Ryear AND Rmon > > [I know I slaughtered your example, but...] > > > > That is: > > - pwdPolicyRule can be expressed using just rule names and logical > > expressions > > - pwdPolicySubrules specify the details of each subrule (name > > of the rule > > instance, OID of the particular policy, and arguments) > > > > That allows individual policies to be mixed and matched, or > > plugged in, > > while having a managable overall policy enforcement that only > > needs to know > > if a given password satifies each sub rule without getting > > bogged down in > > the details of a given rule. > > > > > > John McMeeking > > > > > > "Neal-Joslin, Robert (HP-UX Lab R&D)" wrote on > > 12/08/2004 11:20:16 AM: > > > > > Hi Jim, > > > > > > Thanks for the reply. > > > > > > I did consider using combinations of rules, to help simplify the > > > logic syntax. And I would be happy with it too. But the two main > > > reasons I proposed the "# of" syntax is... First, the number of > > > combinations grow exponentially. Second, when you have to specify > > > arguments to the rule, you need to re-specify a perhaps large set of > > > the same arguments over and over (I need some clarifications on how > > > you propose passing arguments into rules. See below.) > > > > > > I think the real question is, is the "# of" expression valuable? I > > > know of a couple of customers that depend on it for password quality > > > checking. But does that mean we need it? Should LDAP directory > > > servers provide the ultimate password quality checking semantics? > > > > > > On the second point, I'd like to clarify the question I have above > > > about arguments to rules. You said "The specification for any given > > > rule would define mechanisms for the storage of rule-related data." > > > This sounds like something I was proposing earlier, that each rule > > > would need to have it's own set of arguments that it would > > > interpret. This argument list would be a specified within the rule > > > syntax, but would be a data blob. And that no elements within the > > > argument data blob would need to be specified or interpreted by the > > > syntax. Correct? I assume that when you specified the example > > > below, that P1 represents rule1 along with the arguments to rule1. > > > > > > To me I think it's necessary to have the ability to specify > > > arguments to the rules within the pwdQualityRules attribute. For > > > example, suppose we have the "Minimum number of characters" rule. > > > It seems that an argument is required to specify what specific > > > number of characters is the minimum. I suppose it's possible to > > > specify that argument elsewhere, perhaps in a configuration file > > > that the is known to the rule. But that would make it harder to > > > specify a rule set such as "Password must contain at least 10 > > > characters, or be at least 7 characters long and contain a special > > character." > > > > > > Thanks > > > > > > Bob > > > > > > > > > > > > From: Jim Sermersheim [mailto:jimse@novell.com] > > > Sent: Wednesday, December 08, 2004 6:05 AM > > > To: Neal-Joslin, Robert (HP-UX Lab R&D); jmcmeek@us.ibm.com > > > Cc: ldapext@ietf.org; Duane Buss; Tammy Green > > > Subject: RE: [ldapext] Password Policy OIDs > > > > > In general I agree with this approach. For a while I've been > > > thinking that an OID-syntax multi-valued attribute would be > > > sufficient (where each OID represents a rule specified somewhere), > > > and that all rules would always be ANDed (rule specifications could > > > talk more about the semantics of the combinations of certain rules). > > > The specification for any given rule would define mechanisms for the > > > storage of rule-related data (i.e. a dictionary rule might specify > > > that some pwdDictionary attribute be used to hold values like "! > > > (substr(3) dictA)". That way, the list of rules is kept as simple > > aspossible. > > > > > > However, I can see that allowing ORs (and possibly other) operators > > > would be useful. > > > I know a simple syntax allowing AND and OR is not as flexible as > > > what you've described below (where you have "3 of"), but is it > > > sufficient? If we call your criteria below P1 - P6, using only AND > > > and OR we'd have to do this: > > > ( (P1 AND P2 AND P3) > > > OR (P1 AND P2 AND P4) > > > OR (P1 AND P3 AND P4) > > > OR (P2 AND P3 AND P4) > > > ) > > > AND P5 > > > AND P6 > > > > > > Jim > > > > > > >>> "Neal-Joslin, Robert (HP-UX Lab R&D)" > > > 12/6/04 11:10:02 AM >>> > > > Hi John, > > > > > > My apologies for a delayed reply. I've been extremely busy, > > but would > > > still like to follow up. > > > > > > I would just like to follow up on your last question. Are > > we proposing > > > standard policy rules or a method for extending, and > > possibly managing, > > > password policy rules? IMHO, we could define a specific set > > of password > > > policy rules. However, we can not expect that that set of > > rules would > > > be adequate for a typical deployment. Therefore we need to > > look at way > > > to allow for extension of password policies. > > > > > > I personally feel that the draft should include a way for > > customers to > > > define the rules they require for password quality > > checking, doing so > > > out of a collection of rules. Those rules can be defined by > > standards > > > bodies, vendors of directory products, third parties or end > > customers. > > > All we really need is a syntax that allows the directory > > administrator > > > to select from that set. As an example, I think the syntax > > should allow > > > the expression of something like the following. > > > > > > Newly created passwords must, follow 3 of the following 4 > > > requirements: > > > > > > 1) Contain at least one alpha or numeric character > > > 2) Not contain a substring of 3 or more characters that matches > > > a word found in either dictionary A or in dictionary B > > > 3) Be at least 7 characters in length or contain at least 5 special > > > characters. > > > 4) Not contain either the cn, sn or telephone number attributes. > > > > > > And the newly created password must > > > > > > 5) Not be constructed using current year, represented numerically. > > > 6) Not be constructed using the current month, represented either as > > > 2 digits or as a substring of 3 or more characters of the name > > > of the month > > > > > > To clarify, my proposal is not that the draft be able to express the > > > details of those rules, just which rules in which > > combination. I could > > > re-state it as the following... > > > > > > RuleA = Character inclusion > > > RuleB = Dictionary substring exclusion > > > RuleC = Min length > > > RuleD = Attribute substring exclusion > > > RuleE = Current year exclusion > > > RuleF = Current month exclusion > > > > > > Where the syntax might look more like (but not exactly like) > > > > > > Choose 3 OF > > > RuleA "1 of [A-Z,a-z,0-9]"; > > > (RuleB "Dictionary A min 3" AND > > > RuleB "Dictionary B min 3"); > > > (RuleC 7 OR RuleA "5 of [[:Special:]]"); > > > RuleD "cn,sn,telephoneNumber"; > > > AND RuleE > > > AND RuleF > > > > > > My points with the above examples... 1) We can't expect to > > come up with > > > an adequate set of password quality rules and enumerate them in this > > > draft. 2) We need a somewhat complex syntax just to describe which > > > rules to use. > > > > > > In this example, the password quality policy rules are manageable > > > through LDAP, as long as the rules being used are supported by that > > > directory server. > > > > > > Bob > > > > > > , customer envision defining a way for customers to select from a > > > > -----Original Message----- > > > > From: ldapext-bounces@ietf.org > > > > [mailto:ldapext-bounces@ietf.org] On Behalf Of John McMeeking > > > > Sent: Monday, November 15, 2004 6:19 AM > > > > To: ldapext@ietf.org > > > > Subject: Re: [ldapext] Password Policy OIDs > > > > > > > > > > > > > > > > > > > > > > > > I viewed my posts as describing possible mechanisms for > > > > extending password > > > > policy beyond the "basic" password policy defined in this > > > > draft, one using > > > > attributes and auxiliary classes in a schema defined by the > > > > extension, this > > > > latter providing a predefined attribute for the purpose. I > > > > then drew from > > > > other posts to form examples of how these extension > > > > mechanisms might be > > > > used, not intending that those particular policy > > extensions - included > > > > characters, excluded characters - be incorporated into the > > > > password policy > > > > document. > > > > > > > > In that context, debate over whether regex's should be used > > > > vs lists of > > > > characters and whether a dictionary should be in LDAP is > > > > largely academic; > > > > it debate over the design of hypothetical future extensions. > > > > If people are > > > > proposing that these be added to the password policy draft, > > > > then it is a > > > > very relevant discussion. > > > > > > > > As to manageability of features from LDAP... I guess that > > > > depends on where > > > > you want to draw the line. I agree that it is nice if you > > > > don't have to > > > > use one set of tools to manage part of the policy and another > > > > to manage the > > > > rest. On the other hand, other tools/storage mechanism may > > > > be much better > > > > suited to managing these than LDAP. I don't think is > > > > necessary to store > > > > the dictionary in LDAP to be able to effectively manage a > > > > password policy > > > > that uses a dictionary. One may want to share an existing > > > > dictionary used > > > > by other applications. Similarly, if one wanted to use > > > > scripts, I don't > > > > think the scripts need to be stored in LDAP. A file name is quite > > > > adequate. Alternately, the password policy parameters could > > > > contain URLs > > > > referencing an LDAP entry containing a dictionary or perl script. > > > > > > > > If I were designing policies dealing with dictionaries or > > > > scripts, I would > > > > consider designing the policy rule description to allow > > > > either to be used. > > > > The dictionary parameter would be a URL, either a file URL or > > > > a LDAP URL. > > > > Script extensions could be handled similarly. > > > > > > > > So, are we talking about adding specific new policy rules to > > > > this document? > > > > Or are we talking about how password policy could be extended? > > > > > > > > > > > > John McMeeking > > > > > > > > > > > > Howard Chu < hyc@highlandsun.com > wrote on 11/12/2004 > > 05:23:43 PM: > > > > > > > > > Neal-Joslin, Robert (HP-UX Lab R&D) wrote: > > > > > > Hi John, > > > > > > > > > > > > Yes, that is roughly it. See in-line. > > > > > > > > > > >>Its looks more to me like what Bob really was after was a > > > > > >>policy attribute > > > > > >>that could be used to describe any rule -- assuming the > > > > > >>server understood > > > > > >>it. > > > > > >> > > > > > >>In that light, maybe my suggestion was a bit off the mark - > > > > > >>or at least a > > > > > >>quite different approach to the problem. I think it > > > > would be quite > > > > > >>reasonable to define a multi-valued attribute, say > > > > pwdPolicyRule, that > > > > > >>consisted of three parts: > > > > > >>- name for this rule instance > > > > > >>- OID for the rule it describes (server must > > implement this rule & > > > > > >>advertise it?) > > > > > >>- parameters for the rule, perhaps in some XML format - or > > > > > >>maybe the whole > > > > > >>attribute in XML. > > > > > > > > > > In general I dislike adding any feature in LDAP that is not > > > > itself also > > > > > manageable by LDAP. But it appears that there may be no > > other choice > > > > > here. For the Password Policy prototype that Neil Dunbar @ > > > > HP wrote, he > > > > > added an attribute specifying the name of an external > > > > executable program > > > > > to be used to validate the password. That punts the > > > > problem, but you can > > > > > no longer view your entire policy with just an LDAP > > search, you need > > > > > external knowledge. > > > > > > > > > > With respect to external dictionaries, I'd say just use > > > > LDAP search URLs > > > > > and require the dictionary to exist as an LDAP entry. > > > > > > > > > > > XML would be fine, especially for readability. And XML format > > > > > probably should be recommended. But I like the option of leaving > > > > > the encoding up to the implementer. We're assuming that > > XML would > > > > > suit everyone's needs. More importantly, the I would > > argue that we > > > > > can't come up with a single DTD. > > > > > > > > > > XML is ok for representing data. But when you are > > talking about a > > > > > collection of rules and behaviors, what you're talking > > > > about is really a > > > > > program, and what would be best here would be a scripting > > > > language. perl > > > > > would be well suited to the task, and I'm sure there are others. > > > > > > > > > > >>The attribute would use something like a "policy rule name" > > > > > >>matching rule - > > > > > >>i.e. each pwdPolicyRule value must have a unique name. This > > > > > >>would allow > > > > > >>multiple instances of a given rule OID. > > > > > >> > > > > > >>A combination of required chars and excluded character > > > > > >>policies might look > > > > > >>like (pardon my XML): > > > > > >> > > > > > >># requires 2 special characters, 1 from each of these sets: > > > > > >>pwdPolicyRule: rule1 requiredchars-oid > > > chars="!@#$" /> > > > > > >>pwdPolicyRule: rule2 requiredchars-oid > > > chars="%^&" /> > > > > > >># vowels not allowed > > > > > >>pwdPolicyRule: rule3 excludedchars-oid > chars="aeiouAEIOU" /> > > > > > >> > > > > > >>I suppose a better version might be: > > > > > >>pwdPolicyRule: > > > chars="aeiouAEIOU" /> > > > > > >> > > > > > > > > > > > > As I hinted in my last message, we may need an > > optional "Required > > > > > Rule" field. For example, let's suppose I want to encode the > > > > > following policy... > > > > > > > > > > > > "Password must have at least 4 characters and not be in a > > > > > dictionary. It must also contain 3 of the following: 1 > > upper case > > > > > character, 1 lower case character, 1 character of > > '!@#$%^&*()_+=[]-' > > > > > or 1 numeric digit. > > > > > > > > > > > > To encode this, I would need a way to specify that "min 4" and > > > > > "not in dictionary" are required. And in addition, I > > would need a > > > > > rule that says at least 3 of the "non-required" rules must pass. > > > > > > > > > > > > Yes, this is getting ugly. And I don't want to hinder the > > > > > progress of the pwd-policy draft. > > > > > > > > > > -- > > > > > -- Howard Chu > > > > > Chief Architect, Symas Corp. Director, Highland Sun > > > > > http://www.symas.com http://highlandsun.com/hyc > > > > > Symas: Premier OpenSource Development and Support > > > > > > > > > > _______________________________________________ > > > > > Ldapext mailing list > > > > > Ldapext@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/ldapext > > > > > > > > > > > > _______________________________________________ > > > > Ldapext mailing list > > > > Ldapext@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ldapext > > > > > > > > > > _______________________________________________ > > > Ldapext mailing list > > > Ldapext@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ldapext > > > _______________________________________________ > > > Ldapext mailing list > > > Ldapext@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ldapext > > > > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Dec 8 17:26:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16007 for ; Wed, 8 Dec 2004 17:26:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc9jA-00072o-F6; Wed, 08 Dec 2004 16:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc9Hx-0000eS-TX; Wed, 08 Dec 2004 16:23:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04528; Wed, 8 Dec 2004 16:23:55 -0500 (EST) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc9On-0007u5-Ap; Wed, 08 Dec 2004 16:31:02 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB8LNOGW004826; Wed, 8 Dec 2004 16:23:24 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB8LNOeZ280976; Wed, 8 Dec 2004 16:23:24 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB8LNOF1002998; Wed, 8 Dec 2004 16:23:24 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.229.77]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB8LNOpu002971; Wed, 8 Dec 2004 16:23:24 -0500 In-Reply-To: <41B761C9.6090705@highlandsun.com> Subject: Re: [ldapext] Password Policy OIDs To: Howard Chu X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: John McMeeking Date: Wed, 8 Dec 2004 15:23:25 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V70_M3_11102004|November 10, 2004) at 12/08/2004 03:23:24 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Duane Buss , ldapext-bounces@ietf.org, ldapext@ietf.org, Tammy Green , "Neal-Joslin, Robert \(HP-UX Lab R&D\)" , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Howard Chu wrote on 12/08/2004 02:19:21 PM: > John McMeeking wrote: > > > > > > > > You asked if the "# of" expression is valuable? I don't know. The few > > groups I've dealt with don't have rules as complex as "satisfy 3 of 4 rules > > plus the following" unless you were going to try to express "must have n > > letters + at least of the following: number, special character, mixed case > > letters" in that way. I would hope that rule can be expressed as a single > > rule, not "rule1 AND 1 of {rule2, rule3, rule4}" > > > > Like Jim, I expected that an AND of all rules would be sufficient. I know > > I'd hate to be the user trying to figure out what passwords I'll be able to > > use. > > > > If password policy uses something like either your syntax or the AND/OR/... > > suggestion from Jim, I suggest that we try to keep the rules (and their > > arguments) separate from the specification of which rules must be > > satisfied. I'm not feeling very inventive for attribute names, but I'd > > hope it would be something like: > > Yes, I think it would be smart to separate the rule specification from > this point, so as not to slow things down here any further. > > Although I'll reiterate that if you want to express rules that are > applied sequentially and conditionally, you're talking about a program > and a programming language. And I think it is wrong to invent a new > programming language here. Also, we *are* talking about sequential and > conditional application of rules; simple Boolean combinations of a > static set of rules is going to drive everyone crazy. As Robert already > said, the combinations grow exponentially. I agree that this could get out of hand quickly. I offered this only as a "if we must do this then..." I think a simple AND of all rules is sufficient, but that is based on rather limited data. > > > > pwdPolicySubrule: Rinc inclusion-policy-oid > A-Z,a-z,0-9 > > > pwdPolicySubrule: RdictA dictionary-policy-oid > dictionary A > > > pwdPolicySubrule: RdictB dictionary-policy-oid > dictionary B > > > pwdPolicySubrule: Rmin3 minlength-policy-oid > least 3 chars> > > ..... > > pwdPolicyRule: 3 of (Rinc, RdictA, RdictB) AND Ryear AND Rmon > > [I know I slaughtered your example, but...] > > > > That is: > > - pwdPolicyRule can be expressed using just rule names and logical > > expressions > > - pwdPolicySubrules specify the details of each subrule (name of the rule > > instance, OID of the particular policy, and arguments) > > > > That allows individual policies to be mixed and matched, or plugged in, > > while having a managable overall policy enforcement that only needs to know > > if a given password satifies each sub rule without getting bogged down in > > the details of a given rule. > > > > -- > -- Howard Chu > Chief Architect, Symas Corp. Director, Highland Sun > http://www.symas.com http://highlandsun.com/hyc > Symas: Premier OpenSource Development and Support John McMeeking _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext