Subject: [ldapext] Fwd: I-D Action:draft-zeilenga-ldap-passwords-00.txt

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 31 Mar 2008 10:56:11 -0700

This I-D provides an alternative to draft-behera-ldap-password-policy- 
xx.txt.  Appendix provides a discussion of this approach differs, and  
why.

The I-D is a bit rough around the edges...

-- Kurt

Begin forwarded message:
> From: [email-masked]
> Date: March 31, 2008 10:45:01 AM PDT
> To: [email-masked]
> Subject: I-D Action:draft-zeilenga-ldap-passwords-00.txt
> Reply-To: [email-masked]
> List-Id: Internet Draft Announcements <i-d-announce.ietf.org>
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : Passwords in LDAP
> 	Author(s)       : K. Zeilenga
> 	Filename        : draft-zeilenga-ldap-passwords-00.txt
> 	Pages           : 17
> 	Date            : 2008-03-31
>
> The Lightweight Directory Access Protocol (LDAP) provides a number of
>  password-based mechanisms for authenticating directory users to the
>  directory service.  This document discusses the use of passwords in
>  directory user authentication.  The document specifies schema for
>  representing a basic password policy and directory service  
> enforcement
>  of password policy.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-passwords-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
Ldapext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ldapext

---

From: simo <[email-masked]>
Date: Mon, 31 Mar 2008 17:07:21 -0400

> http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-passwords-00.txt

Some comments on the draft:

1)

In the document I see 'pwd' in a former incarnation has been replaced by
'passwd', why not the full 'password' ?

2)

> 3.1.3. 'passwdExpiry'
>
>   The 'passwdExpiry' attribute specifies the age, in seconds, in which a
>   password expires.

This is the number of seconds since the password is changed, right ?

This is in the policy itself, and means all password for users in the
same subtree expire 'passwdExpiry' seconds after their password change
date as recorded by: 'passwdChangeTime'

It is not allowed to have a different expiration time unless a specific
policy is created for the user(s).

With the proposed draft a change in the policy may suddenly expire a
great number of passwords unexpectedly (example: I am changing the
default policy from 90 days to 30 days expiration time).

Another way to handle this is to have passwordExipryTime on the user
entry that express the expiration as generalized time. 'passwdExpiry' in
this case is used at password change time to determine the value of
passwordExipryTime at the time of the change.

This means that followinf changes to the policies do not change the
recorded expiration date for password changes made in the past.

What is the reason for the proposed approach is preferred to this
alternative one ? (I am assuming both have been considered)

3)

4.2. Minimum Length

  The Minimum Length constraint restricts the length of allowed
  passwords, requiring all passwords to have at least the number of
  octets specified in the parameter.  [...]

Here minimum length is expressed in octects, but in UTF-8 multiple
octects can encode for a single character. And therefore a password can
be 'shorter' is simply octect are counted.

Shouldn't the minimum length indicate the minimum number of characters ?

4)

The number of constraints seem quite limited, are you open to suggestion
for more constraint types that are currently commonly used in various
server implementations ?

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <[email-masked]>
Senior Software Engineer at Red Hat Inc. <[email-masked]>

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 31 Mar 2008 16:13:23 -0700

> 'passwd', why not the full 'password' ?

No particular reason.

> This is the number of seconds since the password is changed, right ?

Yes.

> date as recorded by: 'passwdChangeTime'

Yes.

> policy is created for the user(s).

Yes.

> default policy from 90 days to 30 days expiration time).

This is the intended behavior.

> recorded expiration date for password changes made in the past.

Which some may find this to be unexpected behavior.

> alternative one ? (I am assuming both have been considered)

I believe that when the expiration policy is changed from N to M days,  
the policy administrator expects that policy to be applied to all  
passwords, not just those set after the policy change.

> Shouldn't the minimum length indicate the minimum number of  

A password doesn't necessarily consist of character data, so specify  
their length in characters doesn't make any sense.

> for more constraint types that are currently commonly used in various

Yes.

---

From: simo <[email-masked]>
Date: Mon, 31 Mar 2008 20:03:51 -0400

> passwords, not just those set after the policy change.

Thanks, this is the clarification I was seeking.

> their length in characters doesn't make any sense.

In 4.1 you proposed a constraint that password conforms to UTF-8.
In this case data definitely consist of characters.

An administrator, I think, would definitely be confused/disappointed to
discover that the minimum number of characters accepted varies depending
on the language used.
(Most latin languages uses mostly 1 byte characters, while many other
languages will use regularly 2 byte (or more) wide characters).

Should we have a default 'Minimum Length of Characters' constraint to
pair to the UTF-8 constraint of 4.1 ?

> > for more constraint types that are currently commonly used in various

Thanks,
there are some encoding (utf-8) dependent constraints that are widely
used like:

- minimum length in characters
- maximum number of repetitions of the same character in a password
- minimum number of alphabetic characters
- minimum number of lower case characters
- minimum number of upper case characters
- minimum number of digits
- minimum number of special characters (usually ASCII characters that
represent symbols, but may be extended to other symbols in the UTF-8
space)
- minimum number of ASCII characters (as opposed to other utf-8
characters)
- complexity checks, like the checks performed by the cracklib library
to make sure the user name (or other user data) is not used as part of
the password itself, or the password is not too similar to a dictionary
word (locale dependent sometimes).

There is also often a kind of meta-constraint:
- minimum number of constraints that must pass their criteria

This allows a greater number X of constraints but accept the password
even if only Y < X of them is fulfilled. An example configuration is to
enable all constraints but require that only say 4 of them must be met
at the same time to consider the password strong enough.

Simo.

---

From: Howard Chu <[email-masked]>
Date: Mon, 31 Mar 2008 17:23:59 -0700

> word (locale dependent sometimes).

I recall when draft-behera was being discussed that folks wanted more 
constraints, but nobody suggested what those might be. This is a pretty good 
list. As for complexity checks, that may still be more difficult to 
standardize. In OpenLDAP we punt that to a user-written checking module.

I don't really see a good way to fully spec this here, unless you want to 
define an attribute to carry ABNF rules that a password must conform to. Or, 
we could define a list of "dictionaries" that must be checked, where a 
"dictionary" is a specified version number of a well-known word list, library 
(like cracklib) or other external mechanism.

> even if only Y<  X of them is fulfilled. An example configuration is to

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/
_______________________________________________
Ldapext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ldapext

---

From: simo <[email-masked]>
Date: Mon, 31 Mar 2008 22:36:42 -0400

> (like cracklib) or other external mechanism.

I would consider this option features, implementation dependent.

Simo.

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 31 Mar 2008 19:50:10 -0700

> In this case data definitely consist of characters.

Here you use character to mean "code point".  Above I assumed you  
where using character to mean "abstract character".

While a minimum number of code point constraint might be useful, I  
think a minimum number of abstract characters constraints would be  
more useful.  The latter like should be dependent on the SASLprep  
constraint, or other constraint which limited passwords to abstract  
character sequences.

> discover that the minimum number of characters accepted varies  

Or varied depending on the number of code points used to represent the  
abstract character.

> pair to the UTF-8 constraint of 4.1 ?

See above.

> there are some encoding (utf-8) dependent constraints that are widely

I was thinking of just having a Unicode Regular Expression constraint.

-- Kurt

---

From: "Andrew Sciberras" <[email-masked]>
Date: Tue, 1 Apr 2008 16:16:07 +1100

Hi Kurt,

Just some comments that are specific to the administrative model. 

>3.  Password Policy Administrative Model

Administrative Area Scope  
In [BEHERA] it was stated that a password policy could be defined for a
specific user by creating a password policy subentry directly under that
entry. To me, this suggests that password policy administrative points act
like specific administrative areas. 
Is this behavior intended to remain?

Administrative Role
In accordance with X.501 and RFC3672, do you intend to define an
Administrative Role attribute value to identify that a particular
administrative area is concerned with password policy administration?

Multiple Policies  
I assume that the draft allows multiple passwdPolicy subentries to exist
below a given administrative point... This should be explicitly clarified in
the I-D. 
Multiple subentries could be used to allow policies to apply to different
attributes, or to allow different policies to apply to a given password
attribute conditionally, based on the objectClass of an entry (~ using
subtreeSpecification's). 
However, policies may also be created that inadvertently (or otherwise)
conflict with each other. 
Clarifications on this should probably be made to avoid confusion. 

Regards,
Andrew Sciberras
eB2Bcom 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Kurt Zeilenga
> Sent: Tuesday, 1 April 2008 4:56 AM
> To: LDAP Extensions list
> Cc: [email-masked]
> Subject: [ldapext] Fwd: I-D Action:draft-zeilenga-ldap-passwords-00.txt
>

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 31 Mar 2008 22:50:20 -0700

Yes.

Yes.

> Clarifications on this should probably be made to avoid confusion.

My intent is for each entry to be governed by at most one password  
policy,
the policy governing entries within a specific administrative area.

-- Kurt