Subject: [ldapext] password policy: multiple subentries, multiple password attributes, ....

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 5 Jul 2010 14:43:25 -0700

The spec specifically allows for an user entry to be controlled by multiple policies (each for a different password attribute) but then defines pwdPolicySubentry to be single-valued.

It seems to me that the text as a whole doesn't really well consider the implications of multiple applicable password policies.

In our current implementation, we do implement 5.3.1, and mandate that only a single password policy be applicable to a given user.

We currently looking at userPassword v. authPassword implications with regard to auto-migration, as we're now supporting the latter for SCRAM authentication.  I think we'll assume that if both are present in an entry, they represent the same same user password.   We'll like need to support both RFC 2307 hashing and in conjunction with SCRAM authPassword hashing so that users can use either TLS+SimpleBind(WithPassword) or SCRAM.

I don't see the value of having two disjoint password policies, one for each attribute.   What I believe our customers will demand is an unified password policy covering both of these attributes.  (I can see a possible desire to support a disjoint password policy covering passwords for directory application specific passwords, such as when one has a different directory password from say an email password stored in the directory.  However, our customers which have different passwords for different directory applications tend to rely on multiple entries per user, one per directory application (with service-level authorization restrictions), not multiple passwords attributes in a single entry.)

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 5 Jul 2010 14:46:43 -0700

> It seems to me that the text as a whole doesn't really well consider the implications of multiple applicable password policies.

For instance, there is no indication in the PasswordPolicyResponseValue as to which applicable password policy was violated.

-- Kurt

---

From: simo <[email-masked]>
Date: Mon, 05 Jul 2010 17:57:24 -0400

On Mon, 2010-07-05 at 14:43 -0700, Kurt Zeilenga wrote:
> The spec specifically allows for an user entry to be controlled by
> multiple policies (each for a different password attribute) but then
> defines pwdPolicySubentry to be single-valued.
> 
> It seems to me that the text as a whole doesn't really well consider
> the implications of multiple applicable password policies.
> 
> In our current implementation, we do implement 5.3.1, and mandate that
> only a single password policy be applicable to a given user.
> 
> We currently looking at userPassword v. authPassword implications with
> regard to auto-migration, as we're now supporting the latter for SCRAM
> authentication.  I think we'll assume that if both are present in an
> entry, they represent the same same user password.   We'll like need
> to support both RFC 2307 hashing and in conjunction with SCRAM
> authPassword hashing so that users can use either TLS
> +SimpleBind(WithPassword) or SCRAM.
> 
> I don't see the value of having two disjoint password policies, one
> for each attribute.   What I believe our customers will demand is an
> unified password policy covering both of these attributes.  (I can see
> a possible desire to support a disjoint password policy covering
> passwords for directory application specific passwords, such as when
> one has a different directory password from say an email password
> stored in the directory.  However, our customers which have different
> passwords for different directory applications tend to rely on
> multiple entries per user, one per directory application (with
> service-level authorization restrictions), not multiple passwords
> attributes in a single entry.)

Ack, having multiple password policies apply for different attributes
looks simply as an admin nightmare. Password policies tend to be few and
well defined as they are considered critical for the security of the
password. That means that usually it is quite easy to correctly define
all policies for all attributes for a specific subset of users.
Defining them as an intersection of multiple policies seem like a
feature I wouldn't want if I were an administrator. Looks powerful on
paper but also potentially complicated and complex is usually an enemy
of secure.

Simo.

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

---

From: Howard Chu <[email-masked]>
Date: Mon, 05 Jul 2010 15:03:34 -0700

Kurt Zeilenga wrote:
> multiple
policies (each for a different password attribute) but then defines
pwdPolicySubentry to be single-valued.

> It seems to me that the text as a whole doesn't really well consider the
implications of multiple applicable password policies.

I'm pretty sure the intention has always been for only a single policy to 
apply to any given entry. Note that it already explicitly requires only a 
single password value to be present in any entry.

When you see that the spec allows for a different password attribute to be 
used, I take this to mean that within an entire directory, multiple password 
attributes may be used. But for any given entry, it must have only one 
password value, regardless of which attribute carries it.

> only
a single password policy be applicable to a given user.
regard to auto-migration, as we're now supporting the latter for SCRAM
authentication. I think we'll assume that if both are present in an entry,
they represent the same same user password. We'll like need to support both
RFC 2307 hashing and in conjunction with SCRAM authPassword hashing so that
users can use either TLS+SimpleBind(WithPassword) or SCRAM.
>
> I don't see the value of having two disjoint password policies, one for
> each
attribute. What I believe our customers will demand is an unified password
policy covering both of these attributes. (I can see a possible desire to
support a disjoint password policy covering passwords for directory
application specific passwords, such as when one has a different directory
password from say an email password stored in the directory. However, our
customers which have different passwords for different directory applications
tend to rely on multiple entries per user, one per directory application (with
service-level authorization restrictions), not multiple passwords attributes
in a single entry.)

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 5 Jul 2010 15:12:11 -0700

On Jul 5, 2010, at 3:03 PM, Howard Chu wrote:

> I'm pretty sure the intention has always been for only a single policy to apply to any given entry.

Then why the 5.3.1?

> Note that it already explicitly requires only a single password value to be present in any entry.

Single value per password attribute, actually.

> When you see that the spec allows for a different password attribute to be used, I take this to mean that within an entire directory, multiple password attributes may be used. But for any given entry, it must have only one password value, regardless of which attribute carries it.

Again, then why 5.3.1?

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 5 Jul 2010 15:36:45 -0700

On Jul 5, 2010, at 3:03 PM, Howard Chu wrote:

> I'm pretty sure the intention has always been for only a single policy to apply to any given entry. Note that it already explicitly requires only a single password value to be present in any entry.

The introduction of 5.3.1 attribute type options was discussed back in Nov/Dec 2002.  It seems clear to me that the intent was to support separate directory application (userPassword) passwords from directory-enabled service applications (webPassword, emailPassword, etc.).

http://www.openldap.org/lists/ietf-ldapext/200211/msg00026.html

Personally, I'd prefer to restrict the design of this specification to one password per user (no matter how it is stored).  I wouldn't mind seeing password storage policy separated from password use policy.

-- Kurt

---

From: Michael Ströder <[email-masked]>
Date: Thu, 08 Jul 2010 09:35:03 +0200

> paper but also potentially complicated and complex is usually an enemy

Full ack!

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 08 Jul 2010 09:38:22 +0200

Kurt Zeilenga wrote:
> The introduction of 5.3.1 attribute type options was discussed back in
> Nov/Dec 2002.  It seems clear to me that the intent was to support separate
> directory application (userPassword) passwords from directory-enabled
> service applications (webPassword, emailPassword, etc.).

Which was already a broken concept back then.

> Personally, I'd prefer to restrict the design of this specification to one
> password per user

+1

Ciao, Michael.

---

From: Jim Willeke <[email-masked]>
Date: Fri, 9 Jul 2010 09:11:42 -0400

-jim
Jim Willeke

2010/7/8 Michael Ströder <[email-masked]>

> Which was already a broken concept back then.
Perhaps a vendor option?

> > Personally, I'd prefer to restrict the design of this specification to
+1 more.

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