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:
>>> "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