Subject: [ldapext] Re: Password policy state attributes

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 03 Dec 2002 19:13:27 -0700

I guess an unstated goal I've had in the back of my head is to do define the policy state data in such a way that most existing implementations could readilly adopt it. I'm not sure how important that goal is to the rest of the interested parties out there. I would call your ideas radical rather than crackpot--they have the feel of opening up other areas of possiblity.

Jim

>>> Ed Reed 11/22 12:43 PM >>>
At the risk of sounding like a crackpot...
 
You may need to consider something like the X.509 certificate object class discussed in PKIX - an entry with all the policy associated with the particular credential - in this case a password associated with an authentication identity.
 
The X.500 object model used in LDAP simply doesn't make it easy to associate different policy values in one attribute with specific attribute values in another.
 
Better to think of it this way -
 
Each password and its policy is really a user identity with some refinements.  That can be "security equivalent" to a particular user, or perhaps more correctly, the user entry can be "security equivalent" to the password used to log in.  The logic to support such a thing would not be all that different from a login mechanism that allowed a user to select, from a list of allowed roles, those roles the user wanted to assume for a particular login session.
 
It's messy, and fundamentally changes the way people think about identities and their credentials, but in a world where the same identity may use one of several credentials to authenticate, and if it's beneficial to associate different authorization rights with the individual based on which credential they used, it may be a necessary change to consider.
 
Ed

>>> "Jim Sermersheim" <[email-masked]> 11/22/02 12:16PM >>>
A group of people interested in progressing the password policy draft has been growing and exchanging emails off list. We're moving discussion here so we have a list and a wider audience.

The current topic has to do with storing password policy state information for objects. What is needed is a way to store values that represent state information on an object. There is the need to associate the state information with a password. This is because it's desirable to allow multiple passwords per object, and it to be allowed that policy can be described and executed separately for each password. Thus, we need a way of associating each bit of password policy state information with the password it applies to.

For example. There is an attribute called pwdExpirationWarned. This holds the timestamp of when the client was first warned that the password would expire soon, thus it is single-valued. Now, let's say the object that is subject to password policy makes use of three password attributes due to there being three different hard access interfaces: atmPassword, telePassword, and webPassword (think bank account access). When the pwdExpirationWarned attribute is updated (due to an impending  password expiration), there needs to be some way of associating the warning with the password that will expire (let's say it's webPassword).

Our first attempt was to use attribute descriptions with a new tagging option  called "pwd-". In the example above, pwdExpirationWarned;pwd-webPassword would be used to store/retrieve the warning time for the webPassword. The problem that was brought up with this approach (as I remember it) was that since the descr form of attribute types is not canonical, we cannot use it in the attribute option. It would lead to interoperability problems.

Quickly, it was suggested to just use the oid form of the attribute type, like pwdExpirationWarned;pwd-1.2.3.4. While this would solve the problem above, it is an illegal encoding. Attribute options are defined as consisting of ALPHA, DIGIT, and DASH characters.

Then the suggestion of moving the attribute association inside the value was put forth say something like "webPassword#200210240212Z". This requires new syntaxes which some implementors don't like, but worse: 1) It doesn't allow the attributes to be defined as single-value. 2) It doesn't allow the server to enforce uniqueness among the values. 3) It doesn't allow the replace operation (where replace would work with single-valued attributes). None of these limitations are desirable.

I would now like to suggest returning to the first or second suggestion. The first has limitations in a distributed environment, and maybe something can be done about it, but I'm not sure what. The second would be modified to fit the required syntax by replacing dots with dashes. Thus the example would change to: pwdExpirationWarned;pwd-1-2-3-4

Jim

p.s. I can provide a set of recent previous discussions on this and other issues to anyone that wants them.

_______________________________________________
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: "Jim Sermersheim" <[email-masked]>
Date: Tue, 03 Dec 2002 19:00:08 -0700

>>> John McMeeking <[email-masked]> 12/03 7:40 AM >>>
>
>Several scenarios have been described which I think need to be clearly
>distinguished:

Yes, thank's John.

>1.  Multiple userPassword (or attribute) values.  For example, an entry has
>userPassword values "secret" and "anothersecret".  I would prefer that
>password policy attributes apply to the entire set of userPassword values.

I would prefer that password policy is limited to be applied to only single-value password attributes.

>I have a hard time with the notion that "secret" is valid and
>"anothersecret" has been reset, or the notion of a single password being
>locked.  Trying to express that state would require tying the policy
>attributes to individual values and likely that the user know passwords to
>get the values or that the values be returned in clear text to make use of
>the results.  Try searching for all entries with expired passwords or
>figuring out from the results which of the user's passwords were expired.

I agree.

>2.  Multiple password attributes used by the server for authentication of a
>single entry, as opposed to 3, below. I think this would require something
>like simple bind using userPassword, DIGEST-MD5 using authPassword, ...
>This seems like a bit of a stretch, but that may be just my limited
>perspective.  If this is a valid scenario, then I would prefer the approach
>Mark Smith favored:
>   pwdExpirationWarned;pwd-userPassword

Ok. This still allows #3, which is the actual use case that prompted the recent discussion of multiple passwords

>If (2) is considered valid, should the passwordPolicyResponse control be
>changed to indicate which password attribute the warning or error applied
>to?

Yes.

>3.  Multiple password attributes, where applications perform
>authentication.  For example, web app retrieves the webPassword attribute
>and compares it to the user entered string.  I don't see password policy
>applying here.  The server is not performing the authentication function
>(no bind request), making the data no different than telephone numbers from
>a directory server perspective.

Ah, but the application is using the Compare operation. The request is that when password policy is applied to some attribute (that the server itself may never use for authN), that the password policy be applied to the Compare operation. This allows many applications to be written without all having to duplicate password policy checking/enforcement.

>To summarize:
>- The policy attributes like pwdExpirationWarned should apply to all
>password values (possibly multiple values of a single attribute) for an
>entry.  

I disagree here. Why not allow this to be per password attribute (ignoring the problem of multi-value attrs)?

>I do not favor trying to support policy attributes for each
>individual value of a single attribute.

Right--that's ugly.

>-  I don't think multiple password attributes are likely to be used within
>a single entry and used to support bind requests.  I could be persuaded
>otherwise, in which case I would like to see something like:
>   pwdExpirationWarned;pwd-userPassword

I wouldn't want to ignore the possibility

>John  McMeeking

Jim
<snip>