[x500standard] Re: New draft on password policy
- From: "Kemp, David P." <DPKemp@xxxxxxxxxxxxxx>
- To: <x500standard@xxxxxxxxxxxxx>
- Date: Wed, 23 Sep 2009 16:44:39 -0400
David's table indicates that "encrypting" (salted hashing) requires some
knowledge in the DUA for option 2, and I don't claim that standardizing
a method and implementing the standard is trivial. But in principle the
salt would have to be based on either invariant data about the DSA (e.g.
DNS name/port) entered/configured by the user and needed to connect, or
remembered/typed by the user after being randomly generated by the DUA.
Storing it in a DUA-maintained registry/address book would inhibit user
mobility, and storing user-specific salt on the DSA would require an
extra message. If the connection protocol includes a DSA-to-DUA message
before the DUA-initiated BIND, that message could include a DSA ID from
which salt could be derived.
Implementation details aside, protecting clear passwords from DSA
administrators is a legitimate goal, even if TLS is used. And so is
preventing adversaries from collecting clear or unsalted-hashed
passwords for use against other systems, when TLS is not used.
Dave
-----Original Message-----
From: x500standard-bounce@xxxxxxxxxxxxx
[mailto:x500standard-bounce@xxxxxxxxxxxxx] On Behalf Of Kurt Zeilenga
Sent: Wednesday, September 23, 2009 3:25 PM
To: x500standard@xxxxxxxxxxxxx
Subject: [x500standard] Re: New draft on password policy
On Sep 23, 2009, at 9:52 AM, Kemp, David P. wrote:
> The password equivalent applies to the DSA that has stored the hashed
> password. But a hashed password is not equivalent to a clear password
> if the DSA attempts to use it in a different context (e.g. to
> impersonate the user on a different DSA). Of course, humans never
> reuse
> passwords or use related passwords on more than one system, so this
> should never be a problem :-).
How does a DUA determine which salt to use?
-- Kurt
> Dave
>
>
> -----Original Message-----
> From: x500standard-bounce@xxxxxxxxxxxxx
> [mailto:x500standard-bounce@xxxxxxxxxxxxx] On Behalf Of Kurt Zeilenga
> Sent: Wednesday, September 23, 2009 12:41 PM
> To: x500standard@xxxxxxxxxxxxx
> Subject: [x500standard] Re: New draft on password policy
>
>
> On Sep 21, 2009, at 9:28 AM, David Chadwick wrote:
>
>> Hi Howard
>>
>> Here are our responses from today to the issues you raised below. If
>> an issue has not been answered, this means we have not had time to
>> address it yet and will do so tomorrow. Any comments you have on our
>> deliberations so far will be appreciated
>>
>> Howard Chu wrote:
>>> Erik Andersen wrote:
>>>> Hi Folks,
>>>>
>>>> SC6 has made the latest draft of Password Policy available. It may
>>>> be
>>>> downloaded from http://www.x500standard.com/index.php?
>>>> n=Ig.Extension.
>>>>
>>>> SC6 has authorised that we bring this document forward to PDAM
>>>> status
>>>> during the September 2009 meeting.
>>>>
>>>> Please provide comments in time for that meeting.
>>> Based on experience implementing various revisions of the LDAP
>>> Password Policy Draft
>>> http://tools.ietf.org/draft/draft-behera-ldap-password-policy/
>>> and concerns raised in Kurt's newer draft
>>> http://tools.ietf.org/html/draft-zeilenga-ldap-passwords-00
>>> I have several concerns, some related to keeping this X.500 draft
>>> cross-compatible with LDAP, and some related to password policy
>>> management in general.
>>> 1) relying on clients to know that they should be using an
>>> encrypted password, and to know which algorithm to use, seems
>>> impractical in the real world. IMO whether and how the password is
>>> encrypted should be a matter private to the DSA.
>>
>> we still allow this as an option, but we think it is more secure if
>> the directory never knows the user's password so is not able to
>> store it in audit trails or anywhere.
>
> If that's the rationale then shouldn't it apply to all password
> equivalents. If the protocol allows a DUA knowing only the encrypted
> password to gain access, the encrypted password is a password
> equivalent.
>
> -- Kurt
>
> -----
> www.x500standard.com: The central source for information on the X.500
> Directory Standard.
>
> -----
> www.x500standard.com: The central source for information on the X.
> 500 Directory Standard.
>
-----
www.x500standard.com: The central source for information on the X.500
Directory Standard.
-----
www.x500standard.com: The central source for information on the X.500 Directory
Standard.
Other related posts:
