[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: [ldapext] Password Policy OIDs

Hi John,

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

> -----Original Message-----
> From: ldapext-bounces@ietf.org 
> [mailto:ldapext-bounces@ietf.org] On Behalf Of John McMeeking
> Sent: Friday, November 12, 2004 1:25 PM
> To: ldapext@ietf.org
> 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
> 
> 
> 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
> 

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext