Subject: Re: [ldapext] Splitting Password Policy

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 04 Aug 2005 04:27:25 -0600

After talking this over, we've decided to try both. In other words,
splitting the document into four different drafts like this:
 
1) LDAP authentication control for password policy
2) LDAP update control for password policy
3) LDAP password-based authentication policy
4) LDAP password update policy
 
#1 and #2 will essentially define the protocol elements and the various
policy decisions to be made.
#3 and #4 will define the schema elements and how to use them to
implement the policy decisions defined in #1 and #2.
 
We can probably find better names than the ones I've jotted down here.

>>> "Kurt D. Zeilenga" <[email-masked]> 10/26/04 6:21:25 PM >>>
Just a thought, but it might also be useful to split the
protocol elements from the schema elements. The protocol
controls could be genericized to support expiration of
other kinds of credentials.

At 09:00 AM 10/26/2004, Jim Sermersheim wrote:
>All,
> 
>Speaking on behalf of some people on the CC list, it is seen as
desirable to place password update policy in one specification, and
place password use policy in another specification.
> 
>This started as an act of associating password use policy (such as
intruder detection policy) with login policy (such as allowable login
times, addresses, etc).
> 
>It then diverged from that and ended up being described as: Password
policy is policy that applies only to simple bind passwords. Login
policy involves policy that can be applied to *any* kind of
credentials.
> 
>My argument was that policy like password expiration (while enforced
at authN time) is intimately tied to password updates. Thus, if we were
to split this into two I-Ds, there would be some amount of cross
referencing, and cross requirements (password expiration would require
actions during password update).
> 
>I know some people in the community have asked for more "login policy"
type things to be added to the I-D, and we've pushed against adding
those.
> 
>What are other's feelings in this area? (Tammy, Duane, Hal, feel free
to clarify these positions).
> 
>Jim
>_______________________________________________
>Ldapext mailing list
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/ldapext 

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

---

From: Howard Chu <[email-masked]>
Date: Fri, 26 Aug 2005 17:37:11 -0700

One of our customers requested an extension to sort the values in 
multi-valued attributes, which we have now implemented in OpenLDAP 2.3. 
Kurt suggested that we should also provide a (critical) control so that 
new clients can explicitly request this behavior (or disable it). I'm 
thinking we should publish the resulting work as an Informational or 
Experimental RFC.

The extension on the server can be configured to use one of 5 sort 
methods on a particular attributes in particular subtrees of the DIT. 
The first 4 methods are pretty straightforward - alpha ascending, alpha 
descending, and numeric ascending/descending. The 5th method is called 
"weighted" and while the previous 4 methods can be used without any 
special preparation, weighted sorting requires weights to be prefixed to 
the attribute values of interest. The weights are denoted by '{xx}' 
where 'xx' is an integer and are always sorted in ascending order. Also, 
the weights are not returned with the values in normal search results.

So, given an attribute
foo: {10}Animal
foo: {3}Vegetable
foo: {1}Mineral

a search response with weighted sorting would return
foo: Mineral
foo: Vegetable
foo: Animal

Currently the control is defined with a single boolean flag, which if 
set TRUE, disables sorting and causes attributes to be returned as-is.

If it weren't for this weighted sorting method, I would have preferred 
to have no server-side configuration, and just let the client choose its 
sorting parameters completely in the control. That strikes me as the 
most general solution. But this method was specified because they wanted 
  to get the sorting behavior without needing to update existing 
clients, and there's no way you could support weights without 
server-side state information. (And yes, even though there are no 
guarantees about the order of values returned in multi-valued 
attributes, they wrote their clients assuming there was a guaranteed 
order. sigh...)

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

---

From: Richard Megginson <[email-masked]>
Date: Fri, 26 Aug 2005 19:05:25 -0600

Would it be possible to use attribute subtypes for the weights?  This 
could possibly solve a problem for many LDAP users - how to store a list 
of multiple values in order and have the server return them in the same 
order.

Howard Chu wrote:

> multi-valued attributes, which we have now implemented in OpenLDAP 
> 2.3. Kurt suggested that we should also provide a (critical) control 
> so that new clients can explicitly request this behavior (or disable 
> it). I'm thinking we should publish the resulting work as an 
> Informational or Experimental RFC.
>
> The first 4 methods are pretty straightforward - alpha ascending, 
> alpha descending, and numeric ascending/descending. The 5th method is 
> called "weighted" and while the previous 4 methods can be used without 
> any special preparation, weighted sorting requires weights to be 
> prefixed to the attribute values of interest. The weights are denoted 
> by '{xx}' where 'xx' is an integer and are always sorted in ascending 
> order. Also, the weights are not returned with the values in normal 
> search results.
>
> So, given an attribute
> foo: {10}Animal
> foo: {3}Vegetable
> foo: {1}Mineral
>
> to have no server-side configuration, and just let the client choose 
> its sorting parameters completely in the control. That strikes me as 
> the most general solution. But this method was specified because they 
> wanted  to get the sorting behavior without needing to update existing

---

From: Howard Chu <[email-masked]>
Date: Sat, 27 Aug 2005 14:07:23 -0700

> of multiple values in order and have the server return them in the same 

Hm, did you mean actual subtypes, or just attribute options? Something like

foo;x-weight-10: Animal
foo;x-weight-3: Vegetable
foo;x-weight-1: Mineral

That's an interesting idea, although it would still confuse older 
clients that only look for the attribute "foo" in the search responses.

Or did I misunderstand the suggestion?

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 27 Aug 2005 23:50:38 +0200

Howard Chu writes:
>Richard Megginson wrote:
>> Would it be possible to use attribute subtypes for the weights?

Note that this has different semantics in the protocol: It will return
several attributes with one value each instead of one attribute with
several values.

> clients that only look for the attribute "foo" in the search responses.

Well, I the option could be defined with the semantics that it is not
returned in searches.  Maybe unless the user asks for it with a control
or in the attribute list.  Then the server would have to merge returned
attributes that otherwise have the same type, and update operations must
refuse to add values that match a value in another attribute which has
the same type when this option is ignored...

-- 
Hallvard

---

From: Howard Chu <[email-masked]>
Date: Sat, 27 Aug 2005 16:16:39 -0700

Richard Megginson wrote:
> This 

This is a related but different problem, of course. In this case all you 
care about is that a static ordering is preserved. I.e., the client 
stores values in a fixed order and wants them returned in the same 
order. For the "sorted values" problem we're looking for a dynamic 
ordering - the client stores values in an arbitrary order and the server 
rearranges them into a desired order. Another aspect I forgot to mention 
is that for weighted sorting, it's possible for multiple values to have 
the same weight, and you can configure a secondary sort as well (where 
the secondary is one of the other 4 sort types) to handle this case.

Which reminds me, we already have a solution for the static ordering 
problem in OpenLDAP 2.3, adding an "X-ORDERED 'VALUES'" extension to the 
schema definition of the attributeTypes that need it. In this case, we 
also add a {xx} prefix to all of the values of the attribute, but this 
prefix is managed automatically by slapd, is always numbered 
consecutively starting from zero, and is always returned in search 
responses. Pretty sure I posted a full description to this list a few 
months back, but I may be misremembering. The other important aspect of 
this feature is that it allows equality matching of values by prefix. 
Matching by prefix is significant to us because it allows one to 
ldapmodify/Delete specific values by their ordinal position, instead of 
(or in addition to) their actual value. I mainly use this just to avoid 
having to specify long values for deletions, but this also means we can 
delete specific values of multivalued attributes even if they have no 
equality matching rule. Likewise we can provide prefixes on Add 
modifications to insert elements at the specified positions within an 
existing sequence of values. Another (mostly uninteresting) side effect 
of prefix matching is that one can search for e.g. "all attributes that 
have 5 values" by filtering on the prefix.

There is another possibility "X-ORDERED 'SIBLINGS'" that we use as well, 
to preserve the order of peer entries with the same naming attribute. 
This feature is not quite as well-defined; we only use it with 
single-valued RDNs and there are plenty of corner cases I haven't 
thought about.