[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: [ldapext] Password Policy OIDs
Hi Howard,
See in-line.
> -----Original Message-----
> From: Howard Chu [mailto:hyc@highlandsun.com]
> Sent: Friday, November 12, 2004 2:31 PM
> To: Neal-Joslin, Robert (HP-UX Lab R&D)
> Cc: Jim Sermersheim; andrew.sciberras@eB2Bcom.com; ldapext@ietf.org
> Subject: Re: [ldapext] Password Policy OIDs
>
> This all seems rather cumbersome. Speaking from the perspective of a
> server that already uses regexp's and such for processing other
> parameters, it would make sense to me to make this a multivalued
> attribute containing regexp's, all of which must match.
My personal opinion is that regexps are not sufficient to describe all potential rules. As you mentioned below, how would I use a regexp to say that a password must not exist in the dictionary. Or that a password must not contain a substring which is a word from the dictionary that is more than 2 characters long. ...
>
> The one thing this solution doesn't provide is referencing an
> external
> dictionary. In OpenLDAP's identity mapper we use both
> regexp's and LDAP
> URIs to map one identity to another, and that works pretty
> well. For the
> current purpose, I would suggest allowing arbitrary URIs
> (mainly file:
> comes to mind). The meaning could be implicit, as in
> "retrieve the data
> at the given URI and scan its content, if any match is found
> reject the
> password."
So I believe the proposal does cover referencing an external source. It just wasn't explicitly stated as an example.
pwdQualityRule: OID-for-dictionary-check-rule REQUIRED URL
> Or we could define a set of URL extensions that
> specify the
> desired behavior (must match, must not match, etc.).
Not sure I follow how this is different than specifying an OID that identifies the rule. Could you clarify?
>
> Neal-Joslin, Robert (HP-UX Lab R&D) wrote:
> > 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
> >
>
>
> --
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support
>
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext