Subject: RE: [ldapext] Password Policy OIDs

From: "Neal-Joslin, Robert (HP-UX Lab R&D)" <[email-masked]>
Date: Fri, 12 Nov 2004 14:31:15 -0800

Hi John,

Yes, that is roughly it.  See in-line.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of John McMeeking
> Sent: Friday, November 12, 2004 1:25 PM
> To: [email-masked]
> Subject: RE: [ldapext] Password Policy OIDs
> 
> 
> 
> 
> 
> In rereading this, I see I was thrown a bit by the first 
> post, which talked
> about the existing pwdCheckQuality attribute.  As I mentioned 
> earlier, I
> want the existing meaning of that attribute preserved and it 
> is independent
> of what was being described by Bob.
> 
> 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.

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.

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

Bob

> Then each rule can properly define the XML for its rule (I 
> think), as long
> as it has a "name" tag for matching.  I am not XML literate.
> 
> 
> John  McMeeking
> 
> 
> [email-masked] wrote on 11/12/2004 01:43:59 PM:
> 
> > Hi,
> >
> > I agree.  It doesn't go far enough.  My goal was to kick off the
> > idea and hope it moved forward.   For the problems you proposed
> > below, you could simply add more OIDs to represent those rules...
> > It just isn't "nice" to have a OIDs to represent things would
> > require enumerated combinations:
> >
> > OID1 - Must include 1 of "!@#$%^&"
> > OID2 - Must include 2 of "!@#$%^&"
> > OID3 - Must include 1 of "@#$%"
> > OID4 - Must include 1 of "aébz"
> > ... Yuk ...
> >
> > I proposed an OID list because of the simplicity of its syntax.  I
> > didn't want to propose something overly complex, since I inferred
> > from the original syntax that the goal was to keep it simple.
> > Reviewing the other messages, the goal was to avoid specifying
> > password policy quality rules all together.
> >
> > It seems reasonable to me to propose defining OIDs for different
> > password quality rules (and perhaps even registering those OIDs with
> > a recognized registry.)  But for those more complex rules, such as
> > the "2 numeric or special" characters, which require more
> > information that just an OID, we need to understand if it's
> > reasonable to try to include that information in the password
> > quality policy definition as well.
> >
> > If it's reasonable then perhaps a multi-valued attribute with an OID
> > followed by a type-dependent blob.  The blob describes the specific
> > implementation of the rule (using what ever encoding the developer
> > deems appropriate...).
> >
> > "2 of ..." as an example
> > pwdQualityCheckRule: 9.1.2.3.5 2 of 123456790-_+=!@#$%^&*()
> >
> > Perhaps the syntax could define a "Required Rule" field as well.
> > This might be useful when another rule exists that says "password
> > must pass at least 4 of the specified rules."  But one/or some of
> > those rules are required.
> >
> > I could not find information about defining password quality related
> > to SAML's authentication context (at least not a language to help
> > specify rules.)  But I'm not that familiar with SAML enough to know
> > for sure where to look.
> >
> >
> > Thanks,
> >
> > Bob
> >
> >
> >
> >
> > ________________________________
> >
> >    From: Jim Sermersheim [mailto:[email-masked]]
> >    Sent: Thursday, November 11, 2004 5:50 PM
> >    To: [email-masked]; Neal-Joslin, Robert 
> (HP-UX Lab R&D)
> >    Cc: [email-masked]
> >    Subject: RE: [ldapext] Password Policy OIDs
> >
> >
> >    A group of us were just talking about this yesterday. I like the
> > direction it goes in, but it doesn't go far enough. For example, if
> > 9.1.2.3.1 means "minimum of 1 uppercase character", then how do I
> > specify "minimum of 2 uppercase"? Similar problems exist for other
> > quality rules:
> >    - foce the inclusion of two of these special characters "#%&!@"
> >    - Ensure the password isn't a word found at http://www.outpost9.
> > com/files/wordlists/common-passwords.zip.
> >
> >    So I think we need someone to propose a rules language
> > (preferrably one already standardized) which could be used for this
> > purpose. Bob Morgan hinted that SAML authentication contexts might
> > do the trick. I haven't looked at that yet.
> >
> >    Jim
> >
> >
> >
> >    >>> "Neal-Joslin, Robert (HP-UX Lab R&D)" <[email-masked]>
> > 11/11/04 12:40:09 PM >>>
> >    Hi Jim,
> >
> >    I have a highly delayed comment about pwdCheckQuality.
> >
> >    I assume that the OID is intended to define a collection 
> of rules that
> are
> >    used for password strength checking. What do you think 
> about making
> >    pwdCheckQuality a list of OIDs? This means that the list 
> of strength
> rules
> >    are defined by the attribute value, not the OID. For example OID
> >    "9.1.2.3.1" would define "Minimum 1 upper case character 
> required",
> OID
> >    "9.1.2.3.2" would define "No words from a local language
> > dictionary", etc...
> >    Perhaps even another OID "9.1.2.3.3" would say "Password 
> must pass at
> least
> >    80% of the rules defined in pwdCheckQuality."
> >
> >    pwdCheckQuality: 9.1.2.3.1 9.1.2.3.2 9.1.2.3.3
> >
> >    The problem I see with a single OID is that if an administrator
> > finds that a
> >    particular strength rule is troublesome, the only way to 
> disable a
> rule
> >    would be to define a new rule set with a new OID.
> >
> >    Bob
> >
> >
> >
> >    ________________________________
> >
> >    From: [email-masked] 
> [mailto:[email-masked]] On
> >    Behalf Of Jim Sermersheim
> >    Sent: Monday, October 25, 2004 10:16 PM
> >    To: [email-masked]
> >    Cc: [email-masked]
> >    Subject: Re: [ldapext] Password Policy OIDs
> >
> >
> >    Yeah, I suppose we could do that as well. I'm looking at the
> >    differences between the 00 version and the 09 version:
> >
> >    For the pwdPolicy class:
> >    - pwdDefaultStorageScheme has been dropped
> >    - pwdFailureCountResetTime has changed to pwdFailureCountInterval
> >    - pwdGraceLoginLimit has changed to pwdGraceAuthNLimit
> >    - pwdCheckSyntax has changed to pwdCheckQuality. It's 
> syntax changed
> >    from boolean to integer, but I'm proposing to chainge it to oid
> >
> >    - pwdAttribute has been added as a MUST
> >    - The usage of all attributes on pwdPolicy has changed from
> >    directoryOperation to userOperation
> >    - The OID assigned to all attribute has changed at least once
> >
> >    There used to be a pwdInfoObj aux class which defined the state
> >    attribute. That's gone, but the attributes have gone 
> through these
> changes:
> >    - pwdExpirationTime and pwdAllowChangeTime have been replaced by
> >    pwdChangedTime
> >    - pwdExpWarned has been dropped
> >    - pwdRetryCount and pwdRetryCountResetTime have been replaced by
> >    pwdFailureTime
> >    - pwdAccountUnlockTime has been replaced by pwdAccountLockedTime
> >    - pwdGraceLeft has been replaced by pwdGraceUseTime
> >    - The data format of pwdHistory has changed
> >    - pwdReset has been added
> >    - pwdPolicySubEntry has been added
> >    - The OIDs of these have all changed at least once as well
> >
> >    Version 04 (July 2001) introduced the OIDs (prior to that, they
> >    actually used OIDs relative to an unnamed arc. Less has changed
> between the
> >    04 and 08 versions in the schema definitions, but 
> semantic changed
> >    (including buggy specifications) have changed over those four
> versions. I
> >    also believe most implementations were written to one of 04 - 07
> >
> >    So, it seems a good time to me to update the OIDs, as well as the
> >    names. I prefer to keep names that I don't believe will change
> > syntactically
> >    or semantically. These include:
> >    pwdMinAge, pwdMaxAge, and pwdInHistory (though I might like
> >    pwdHistorySize better), pwdHistory (though I can see the format
> possibly
> >    changing, thus a name change would be good), and 
> pwdPolicySubentry. I
> can
> >    think of similar or better names for the rest of them.
> >
> >    Jim
> >
> >    >>> Andrew Sciberras < [email-masked] > 
> 10/25/04 8:11:01
> >    PM >>>
> >    G'Day Jim,
> >
> >    I think that this is a good idea, however your email 
> suggests that
> >    changing the OID's will disambiguate the semantics by which a
> >    password
> >    policy is being enforced. Do you plan to change the short name
> >    descriptors of the attributes as well?
> >
> >
> >    Andrew Sciberras
> >
> >
> >    Jim Sermersheim wrote:
> >
> >    > This does bring up another point I wanted to discuss though...
> >    >
> >    > This draft was written way back when it was popular to 
> assign OIDs
> >    in
> >    > I-D's. A practice that has lost favor partly due to
> >    implementations
> >    > using those OIDs and experiencing problems as semantics changed
> >    but OIDs
> >    > didn't.
> >    >
> >    > I'd like to move this I-D forward, and I don't want to 
> be tied to
> >    any
> >    > semantics defined in previous versions. I propose that 
> we replace
> >    the
> >    > existing OIDs with requests for IANA OIDs. This way, existing
> >    > implementations won't appear to be invalid according to the
> >    current and
> >    > future revisions, and I won't have to worry so much 
> about breaking
> >    > existing implementations.
> >    >
> >    > What do other's think?
> >    >
> >    > Jim
> >    >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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: Howard Chu <[email-masked]>
Date: Fri, 12 Nov 2004 15:23:43 -0800

>>- parameters for the rule, perhaps in some XML format - or 

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 s…

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.

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.       Director, Highland Sun
   http://www.symas.com               http://highlandsun.com/hyc
   Symas: Premier OpenSource Development and Support

---

From: John McMeeking <[email-masked]>
Date: Mon, 15 Nov 2004 08:19:10 -0600

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:

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

---

From: Neil Dunbar <[email-masked]>
Date: Mon, 15 Nov 2004 07:05:32 -0800

> no longer view your entire policy with just an LDAP search, you need 

Oh the out-of-band checker was never meant to be a permanent solution -
just a way of getting something in place.

> and require the dictionary to exist as an LDAP entry.

I like this idea - have a dictionary in the DIT.

Since we're into ppolicy wishlists. I'd like to see something in a
policy specification which states that the password can not contain
literal combinations of specified attributes. For example

pwdPolicyExcludedAttribute: cn
pwdPolicyExcludedAttribute: sn

meaning that the password can't contain the common name of the entry, or
the surname. And then the dictionary attribute becomes an LDAP search as
Howard suggests.

Cheers,

Neil

---

From: Neil Dunbar <[email-masked]>
Date: Mon, 15 Nov 2004 07:08:32 -0800

On Mon, 2004-11-15 at 08:19 -0600, John McMeeking wrote:

> by other applications

Definitely - but there's no reason that an LDAP backend can't simply
present a read-only, searchable front-end to the standard dictionary
file. It doesn't follow that the LDAP interface must have a true
database behind it.

Cheers,

Neil