[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] Password Policy OIDs
Howard Chu <hyc@highlandsun.com> 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 <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.
>
>
>
> --
> -- 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