RE: [ldapext] Password Policy OIDs

[John McMeeking <jmcmeek@us.ibm.com>]

"Neal-Joslin, Robert (HP-UX Lab R&D)" <bob.joslin@hp.com> 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 <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