Subject: RE: [ldapext] Password Policy OIDs

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 11 Nov 2004 18:49:54 -0700

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

---

From: John McMeeking <[email-masked]>
Date: Fri, 12 Nov 2004 10:01:26 -0600

This discussion on pwdQualityCheck seems to have a few conflicting thrusts:

- The original attribute describes how the policy should be applied to
hashed passwords.  I think that is a valuable thing to preserve and is
largely independent of the specifics of a given policy.  *** Lets please
keep this notion. ***

- The recent discussion (and notes in the draft) seem to morph
pwdQualityCheck into a mechanism for specifying what password policies are
in effect.  That is useful, but also has nothing to do with (and is
independent of) of the previous meaning of pwdQualityCheck.  I suggest that
such a list of policies could be handled as described below.

You'll never be able to define a single model that does what everybody
needs (as in "we aren't allowed to buy your product if it won't do 'X'").
I think this document should confine itself to defining a standard set of
policy rules that is widely useable and provide a framework for vendors to
provide either additional policies or mechanisms for customers to implement
their own policies.

It was previously suggested that this draft be split into multiple pieces -
or at least that it try to make the pwdPolicy objectclass, the operational
attributes, and the controls reasonably independent.  Pat of the idea was
that someone should, for example, be able to use a different policy without
throwing out everything else.

I think it would be appropriate for this document to define a "Basic
Password Policy" (to borrow from X.500 access control terminology).  The
policy description consists of various objectclasses and various
attributes.  The objectclasses define the specific policy implementations
("basic password policy"); the attributes can be borrowed by other password
policy implementations, or augmented with additional attributes.  You
already have this, but maybe it needs to say it better, and provide a
little more framework for extensibility.

1) A subentry with an "password policy" administrativeRole (to identify a
password policy subentry) defines the policy for a subtree of entries.

2) An auxiliary class that contains the elements of this basic password
policy, pwdPolicyObject, is added to the above subentry.

3) Other password policy auxiliary classes can be defined.  These classes
can be used instead of, or in addition to, the pwdPolicyObject defined
above.  For example, an implementation might define a
"localDictionaryPwdPolicy" objectclass, possibly with attributes
identifying the dictionary to be used.

If changing the set of auxiliary classes for an entry to change the policy
is deemed unwieldly, you could introduce an additional auxiliary class, say
pwdPolicySchemes, that contains a single multi-valued attribute,
pwdPolicyScheme.  The values of the attribute could be the names of the
relevent auxiliary classes (or their OIDs).  Basic password policy + local
dictionary would look like:

cn=pwdpolicy,<subtree>
objectclass: subentry
objectclass: pwdpolicyschemes
objectclass: pwdpolicyobject
objectclass: localdictionarypolicy
administrativerole: <pwdpolicyrole-oid>
pwdpolicyscheme: pwdpolicyobject-oid
pwdpolicyscheme: localdictionarypwdpolicy-oid  <- delete this value to
disable the dictionary policy
[attributes from pwdpolicyobject]
[attributes from localdictionarypwdpolicy]

Perhaps pwdPolicySchemes objectclass would be optional.  If not present,
all the auxiliaryclasses and their attributes are considered to be in
force.

John  McMeeking

"Jim Sermersheim" <[email-masked]> wrote on 11/11/2004 07:49:54 PM:

> - 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,
>
are
rules
> "9.1.2.3.1" would define "Minimum 1 upper case character required", OID
etc...
least
that a
> particular strength rule is troublesome, the only way to disable a rule
the
> (including buggy specifications) have changed over those four versions. I
syntactically
> pwdHistorySize better), pwdHistory (though I can see the format possibly
> changing, thus a name change would be good), and pwdPolicySubentry. I can

---

From: Ludovic Poitou <[email-masked]>
Date: Fri, 12 Nov 2004 18:02:52 +0100

>largely independent of the specifics of a given policy.  *** Lets please
I fully agree.

>needs (as in "we aren't allowed to buy your product if it won't do 'X'").
I also agree with this.

Overall, I like this proposal.
Can it be restricted to a pwdQualityCheckPolicy or do you forsee other 
areas where you might want to extend the policy ?

Ludovic.

-- 
Ludovic Poitou
Directory Architect.
Directory Server Group, Grenoble, France
Sun Microsystems Inc.

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or
distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy
all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: John McMeeking <[email-masked]>
Date: Fri, 12 Nov 2004 12:16:19 -0600

Ludovic Poitou <[email-masked]> wrote on 11/12/2004 11:02:52 AM:

> > ...

I think this would be a general password policy extension mechanism.
The current pwdPolicyObject already goes beyond password quality:
- pwdMustChange
- pwdSafeModify
- pwdGraceAuthNLimit
- lockouts

Password quality seems the most likely area of extension, but I see no
reason to restrict extensions to quality.

John McMeeking