|
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