How common is the "multiple passwords" scenario in real world
deployments? My impression is that it is very rare. If so, I am
opposed to doing extensive engineering and adding complexity for
implementors and users in order to support it. I think most people
will be happy with a password policy specification that only supports
one password attribute. But if we really need support for more than
one, I vote for the:
pwdExpirationWarned;pwd-userPassword
pwdExpirationWarned;pwd-webPassword
approach. If we require that all attribute types used in conjunction
with password policy be registered with IANA, I don't think there will
be any serious interoperability problems with this approach.
-Mark Smith
Netscape
Jim Sermersheim wrote:
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
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext