Subject: RE: [ldapext] Password Policy OIDs

From: "Neal-Joslin, Robert (HP-UX Lab R&D)" <[email-masked]>
Date: Wed, 8 Dec 2004 09:20:16 -0800

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:[email-masked]] 
Sent: Wednesday, December 08, 2004 6:05 AM
To: Neal-Joslin, Robert (HP-UX Lab R&D); [email-masked]
Cc: [email-masked]; 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.
	 
	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)" <[email-masked]>
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: [email-masked] 
	> [mailto:[email-masked]] On Behalf Of John McMeeking
	> Sent: Monday, November 15, 2004 6:19 AM
	> To: [email-masked] 
	> 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 < [email-masked] > 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://www.symas.com/>
http://highlandsun.com/hyc 
	> > Symas: Premier OpenSource Development and Support
	> >
	> > _______________________________________________
	> > Ldapext mailing list
	> > [email-masked] 
	> > https://www1.ietf.org/mailman/listinfo/ldapext 
	> 
	> 
	> _______________________________________________
	> Ldapext mailing list
	> [email-masked] 
	> https://www1.ietf.org/mailman/listinfo/ldapext 
	> 
	
	_______________________________________________
	Ldapext mailing list
	[email-masked] 
	https://www1.ietf.org/mailman/listinfo/ldapext 

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: John McMeeking <[email-masked]>
Date: Wed, 8 Dec 2004 13:50:47 -0600

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)" <[email-masked]> 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."

> 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.
> 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
>
> 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
> 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
> 3) Be at least 7 characters in length or contain at least 5 special
> characters.
> 5) Not be constructed using current year, represented numerically.
> 6) Not be constructed using the current month, represented either as
> 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
> 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
> > used, not intending that those particular policy extensions - included
> > think the scripts need to be stored in LDAP. A file name is quite
> > referencing an LDAP entry containing a dictionary or perl script.
> >
> > Howard Chu < [email-masked] > wrote on 11/12/2004 05:23:43 PM:
> >
> > > >>In that light, maybe my suggestion was a bit off the mark -
> > > >>or at least a
> > > >>- OID for the rule it describes (server must implement this rule &
> > > >>advertise it?)
> > > manageable by LDAP. But it appears that there may be no other choice
> > > no longer view your entire policy with just an LDAP search, you need
> > > external knowledge.
> > >
> > > > 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
> > > XML is ok for representing data. But when you are talking about a
> > > 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
> > > >># requires 2 special characters, 1 from each of these sets:
> > > >>pwdPolicyRule: rule3 excludedchars-oid <rule chars="aeiouAEIOU" />
> > > >>
> > > > As I hinted in my last message, we may need an optional "Required
> > > 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.
> > > >
> > > http://www.symas.com http://highlandsun.com/hyc

---

From: Howard Chu <[email-masked]>
Date: Wed, 08 Dec 2004 12:19:21 -0800

> 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.

---

From: John McMeeking <[email-masked]>
Date: Wed, 8 Dec 2004 15:23:25 -0600

> 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.

John  McMeeking