Subject: Re: [ldapext] Re: Password policy state attributes

From: Jim Willeke <[email-masked]>
Date: Mon, 02 Dec 2002 21:29:54 -0500

As a "Real" worl example, we are using multiple password as one is 
"sync'd" to an iPlanet server and is stored in sha-1 format another is" 
sync'd" to a "home-grown" application and is in MD-5 and then the third 
is the "normal" LDAP password.

A reason we store them all in the directory ? The user goes to one WEB 
site to chang e thier password and all passwords are updated from the 
WEB sit eto the directory. Then a background process copies the password 
to the places they need to be copied.
-jim

Mark C Smith wrote:

> 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
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/ldapext
>
>
>
> _______________________________________________
> 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: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 02 Dec 2002 19:07:51 -0800

The example you give is for multiple encodings of the same password,
not multiple passwords.  I am sure there are real world examples
of multiple passwords.  I've seen them to manage password transitions.
That is one might have both the new and old passwords stored in
userPassword during a transitional period. 

Then there is an issue of multiple password attributes (e.g.
userPassword v. authPassword).

Personally, I think the password policy should minimally support
multiple values of userPassword...

Kurt

At 06:29 PM 2002-12-02, Jim Willeke wrote:
>As a "Real" worl example, we are using multiple password as one is "sync'd" to an iPlanet server and is stored in sha-1 format another is" sync'd" to a "home-grown" application and is in MD-5 and then the third is the "normal" LDAP password.
>
>A reason we store them all in the directory ? The user goes to one WEB site to chang e thier password and all passwords are updated from the WEB sit eto the directory. Then a background process copies the password to the places they need to be copied.
>-jim
>
>Mark C Smith wrote:
>
>>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:
>>
>>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.
>>>

---

From: "Andrew Sciberras" <[email-masked]>
Date: Tue, 3 Dec 2002 14:59:41 +1100

Hi

I think that it is important to consider whether the Password Policy should
be able to support password values that are stored using options ( Egg.
userPassword;x-exampleOption ).

If it should, then the password policy state attributes must use more than
just the object identifier of the password attribute to make an association
between the state information and the password value which it applies to.

Andrew.

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Tuesday, 3 December 2002 14:08
> To: Jim Willeke
> Cc: Mark C Smith; Jim Sermersheim; [email-masked];
> [email-masked]; [email-masked]; Alan Clark; Hal
> Henderson
> Subject: Re: [ldapext] Re: Password policy state attributes
>
>
> >As a "Real" worl example, we are using multiple password as
> one is "sync'd" to an iPlanet server and is stored in sha-1
> format another is" sync'd" to a "home-grown" application and
> is in MD-5 and then the third is the "normal" LDAP password.
> >
> >A reason we store them all in the directory ? The user goes
> to one WEB site to chang e thier password and all passwords
> are updated from the WEB sit eto the directory. Then a
> background process copies the password to the places they
> need to be copied.
> >-jim
> >
> >Mark C Smith wrote:
> >
> >>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:
> >>
> >>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
> >>>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.
> >>>