Re: [ldapext] Re: Password policy state attributes

[John McMeeking <jmcmeek@us.ibm.com>]

Several scenarios have been described which I think need to be clearly
distinguished:

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 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.

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

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

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.


To summarize:
- The policy attributes like pwdExpirationWarned should apply to all
password values (possibly multiple values of a single attribute) for an
entry.  I do not favor trying to support policy attributes for each
individual value of a single attribute.
-  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


John  McMeeking



                                                                                                                        
                      "Kurt D.                                                                                          
                      Zeilenga"                To:       Jim Willeke <jim@willeke.com>                                  
                      <Kurt@OpenLDAP.or        cc:       Mark C Smith <mcs@netscape.com>, Jim Sermersheim               
                      g>                        <jimse@novell.com>, ldapext@ietf.org, andrews@adacel.com.au,            
                      Sent by:                  bcheckley@epresence.com, Alan Clark <ACLARK.PRV-3.PROVO@novell.com>,    
                      ldapext-admin@iet         Hal Henderson <HAL@novell.com>                                          
                      f.org                    Subject:  Re: [ldapext] Re: Password policy state attributes             
                                                                                                                        
                                                                                                                        
                      12/02/2002 09:07                                                                                  
                      PM                                                                                                
                                                                                                                        
                                                                                                                        



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:
>>
>>    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
>
>
>_______________________________________________
>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



_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext