Subject: authmeth: password issues

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 14 Mar 2004 22:32:47 +0100

I'd like to see a section like the following in Authmeth, to help people
decide which authentication methods to support and what password
security to expect.  Note that some of my terminology may be bad.

   12. Password issues

   Simple authentication (Simple Bind with DN and password) reveals the
   user's password to the server.  The SASL DIGEST-MD5 mechanism does
   not.

   Neither Simple authentication nor DIGEST-MD5 require the server to
   know the users' passwords; both allow the server (or a password
   management entity which the server makes use of) to only store
   one-way hashes of the passwords.  Whether to actually do so is an
   implementation and deployment decision.

   However, an attacker (or the server administrator) who possesses a
   server's DIGEST-MD5 password hashes can authenticate to that server
   even though he does not know the plaintext passwords.

   The SASL EXTERNAL mechanism does not involve passwords, though the
   external method it uses to establish credentials may do so.  If it
   uses TLS certificates, these neither reveal the user's secret to the
   server nor require the server to know the user's secret.

   Anonymous and unauthenticated Simple Binds do not involve passwords
   or other secrets.

The part about compromised DIGEST-MD5 password hashes is from message
<http://www.openldap.org/lists/ietf-ldapbis/200309/msg00077.html>.
In that message, Alexey also said:

   I believe it is possible to store a salted version of the hash,
   assuming the server always generates nonce-value that uses the salt
   as the prefix. But of course this salted hash will be different from
   traditional UNIX salted hashes.

However, looking at the [DIGEST-MD5] hash function, I do not see how
that is possible, since it includes the MD5 hash [RFC1321] of, roughly,
"username:realm:password".  If it is not possible, then the paragraph
above about compromised DIGEST-MD5 password hashes should end with:

   The server administrator will need the plaintext of all the server's
   DIGEST-MD5 passwords in order to generate a new set of secret
   DIGEST-MD5 password hashes, or all users with passwords unknown to
   the administrator will need new passwords so one can generate new
   hashes.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 18 Mar 2004 19:40:36 -0800

At 01:32 PM 3/14/2004, Hallvard B Furuseth wrote:
>security to expect.

Are you trying to help implementor to decide which mechanisms
to support, or help deployers to decide which mechanisms to
use?  I gather the latter.

I would rather this focus more on the former (as our primary
audience is implementors of LDAP).  In particular, it could
note that while DIGEST-MD5 is specifically designed to allow
storage of a realm-specific but password-equivalent hash of
the password.  Servers implementing simple DN/password mechanism
in addition to DIGEST-MD5, have three basic choices:
        1) use the DIGEST-MD5 hash to verify the simple password;
        2) store the actual password: generating the DIGEST-MD5
        hash as needed, using it directly for simple password; or
        3) store both the DIGEST-MD5 hash and a separate hash
        of the password for use in verifying the simple password.

It might be useful to briefly describe the trade-offs.

1) doesn't work to well if you also need to support
a mechanism that require another hash of the password, but
if you're only supporting DIGEST-MD5 and simple (and PLAIN),
1) seems better than 2).

2) is appropriate where a server needs to support multiple
authentication mechanisms which either require knowledge
of the password, or differing hashes of the password.

3) doesn't scale well to multiple mechanisms... only is as
strong as weakest hash, but even less due to added complexity.

One of the reasons for incorporating SASL into LDAP is that
if major new attacks are found with DIGEST-MD5, it can easily
be replaced.  Hence, I generally think 2) is the best
implementation approach.

>   the administrator will need new passwords so one can generate new

Note that the server can obtain the user's password by
forcing use of simple bind until the user's entry in
the new database is prepared, using the old database
for verification of the simple bind used prepare the
entry in the new database.  (The old database should
not be used for DIGEST-MD5 for obvious reasons.)
Where a a server supports realm transition, the
administrator just needs to tell the supporting server
to undertake the transition.

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 19 Mar 2004 11:11:58 +0000

>strong as weakest hash, but even less due to added complexity.
Kurt, I will point out that what you've written is not specific to LDAP. 
So it might be better if this is incorporated into DIGEST-MD5 itself.

>to undertake the transition.
Alexey

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 19 Mar 2004 09:28:51 -0800

At 03:11 AM 3/19/2004, Alexey Melnikov wrote:
>Kurt, I will point out that what you've written is not specific to LDAP. So it might be better if this is incorporated into DIGEST-MD5 itself. 

That would seem appropriate.  I note the PLAIN TS does briefly
discuss that PLAIN might be used to prep a DIGEST-MD5 hash
database.  It might be appropriate for [AuthMeth] to briefly
discuss that simple DN/password mechanism might be used for
this as well.

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 19 Mar 2004 17:43:49 +0000

>discuss that simple DN/password mechanism might be used for
Make sense.

Alexey