[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: [ldapext] Re: Password policy state attributes
Hi 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 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 think that the original intention of the Password Policy (as specified in
section 3.3) should still apply, in that the password attributes to which
the policy applies should only have one value.
Attempting to tie the password policy to particular values would definitely
be a bit of a nightmare for all the reasons that you've mentioned plus the
fact that not all state attributes can apply to values. For example, the
pwdHistory state attribute must be associated with an attribute.
> 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.
I disagree.
The current state of the Password Policy allows the web application to
'offload' user authentication to the server in the form of a compare
operation.
Section 6.4 of the draft discusses how a compare operation should be
handled. A web application only needs to send the 'user entered string' to
the directory in a compare operation to validate whether the provided
password is correct. I believe that the Password Policy should be applied in
this instance as the compare operation being made by the web application is
equivalent to a bind.
Perhaps the Policy should also be extended to treat some search operations
as being equivalent to a bind as well.
>From a security point of view it is also much safer to send the user entered
text to the server rather than send the actual password to the web app, this
is beside the point though.
in summary I support the fact that:
* the Password Policy should only support attributes with a single password
value,
* the Password Policy may apply to multiple attributes within a single
entry,
* the Password Policy should apply to password attributes and not values,
* the state attributes should have a complex syntax which includes (as part
of the value the value) the AttributeDescription of the password attribute
to which the value applies. The AttributeDescription would contain the
AttributeType plus any options. In this case the AttributeType should
contain the dotted-decimal OBJECT IDENTIFIER of the attribute and not its
textual name.
Cheers,
Andrew Sciberras.
>
>
> 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
>
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext