[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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.
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" />
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
ldapext-bounces@ietf.org 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:jimse@novell.com]
> Sent: Thursday, November 11, 2004 5:50 PM
> To: andrew.sciberras@eB2Bcom.com; Neal-Joslin, Robert (HP-UX Lab R&D)
> Cc: ldapext@ietf.org
> 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)" <bob.joslin@hp.com>
> 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: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org] On
> Behalf Of Jim Sermersheim
> Sent: Monday, October 25, 2004 10:16 PM
> To: andrew.sciberras@eB2Bcom.com
> Cc: ldapext@ietf.org
> 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 < andrew.sciberras@eB2Bcom.com > 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
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext