RE: [ldapext] Password Policy OIDs

["Neal-Joslin, Robert (HP-UX Lab R&D)" <bob.joslin@hp.com>]

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
 

> -----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 <data for this rule --
> A-Z,a-z,0-9 >
> pwdPolicySubrule: RdictA dictionary-policy-oid <data for this rule --
> dictionary A >
> pwdPolicySubrule: RdictB dictionary-policy-oid <data for this rule --
> dictionary B >
> pwdPolicySubrule: Rmin3 minlength-policy-oid <data for this rule -- at
> 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)" <bob.joslin@hp.com> 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)" <bob.joslin@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 = 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 <rule count="1"
> > > chars="!@#$" />
> > > > >>pwdPolicyRule: rule2 requiredchars-oid <rule count="1"
> > > chars="%^&" />
> > > > >># vowels not allowed
> > > > >>pwdPolicyRule: rule3 excludedchars-oid <rule 
> chars="aeiouAEIOU" />
> > > > >>
> > > > >>I suppose a better version might be:
> > > > >>pwdPolicyRule: <excludedCharsRule name="rule3"
> > > 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