Subject: RE: [ldapext] Password Policy OIDs

From: "Neal-Joslin, Robert (HP-UX Lab R&D)" <[email-masked]>
Date: Thu, 11 Nov 2004 09:40:09 -0800

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: "Neal-Joslin, Robert (HP-UX Lab R&D)" <[email-masked]>
Date: Fri, 12 Nov 2004 14:41:59 -0800

Hi Howard,

See in-line. 

> -----Original Message-----
> From: Howard Chu [mailto:[email-masked]] 
> Sent: Friday, November 12, 2004 2:31 PM
> To: Neal-Joslin, Robert (HP-UX Lab R&D)
> Cc: Jim Sermersheim; [email-masked]; [email-masked]
> 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:[email-masked]] 
> > 	Sent: Thursday, November 11, 2004 5:50 PM
> > 	To: [email-masked]; Neal-Joslin, Robert 
> (HP-UX Lab R&D)
> > 	Cc: [email-masked]
> > 	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)" 
> <[email-masked]> 11/11/04 12:40:09 PM >>>
> > 	Hi Jim,
> > 	
> > 	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.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."
> > 	
> > 	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
> > 	- pwdCheckSyntax has changed to pwdCheckQuality. It's 
> syntax changed
> > 	from boolean to integer, but I'm proposing to chainge it to oid
> > 	
> > 	attribute. That's gone, but the attributes have gone 
> through these changes:
> > 	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:
> > 	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 
> > 	> This draft was written way back when it was popular 
> to assign OIDs
> > 	in
> > 	> 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
> > 	> future revisions, and I won't have to worry so much 
> about breaking
> -- 
>    -- Howard Chu
>    Chief Architect, Symas Corp.       Director, Highland Sun
>    http://www.symas.com               http://highlandsun.com/hyc
>    Symas: Premier OpenSource Development and Support
>