[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: multi-valued userPassword (was: IETF ldapbis WG Last Call: draft-ietf-ldapbis-user-schema-05.txt)



At 01:43 AM 5/27/2003, Michael Ströder wrote:
>Another issue:
>Any reasonable *and* secure use-case for having multi-valued userPassword?

Yes.  Consider an environment where every month the user was expected
to use a different password generated by some automated system.  During
transitional periods, like say the last and first day of the periods, it
may be reasonable to allow two passwords for the two consecutive periods
to be valid in the system.

>Maybe it's worth to note in section 'Security Considerations' that multiple attribute values for userPassword should be avoided. Especially reset/deletion of a password by an admin without knowing the old user password gets tricky or impossible if multiple values for different applications are present. This also somewhat relates to a similar discussion on ldap-ext list about possibly multi-valued attributes in draft-behera-ldap-password-policy.

First, I note that the descriptive text in section 2.40 (as well as most every
other 2.x section) needs to be updated to describe the attribute type in
multi-valued terms.  It should be noted that when used for authentication
purposes [AuthMeth], the user need only prove she knows one of the values, not
all of the values.

Allowing multiple values obviously does raise a number of security considerations
and these need to be discussed in the document.

Certainly applications which intend to replace the userPassword with new value(s)
should use modify/replaceValues (or modify/deleteAttribute+addAttribute).
Additionally, server implementations should be encouraged to provide
administrative controls which, if enabled, restrict userPassword to one value.

>The only use-case I could imagine for having multiple userPassword attribute values was working around the Octet String problem storing the *same* password with various character sets/encodings.

Supporting legacy systems would be another reason.