Subject: Re: comments to draft-ietf-ldapbis-authmeth-04.txt

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 11 Sep 2003 21:29:44 +0200

I'm still wondering about SASL/DIGEST-MD5...

In an old private mail to Roger Harrison, I wrote:

> [Under Security Considerations in Authmeth,]
> 
> Please mention (...) which mechanisms that are standardized by the
> LDAP standard do/do not disclose the user's password to the server?

Another thing which would be interesting to list is which methods
need/don't need the server to know the user's plaintext password.
(I say 'know' instead of 'store' because it could still store the
password encrypted, but in a way which it knows how to decrypt.)

The best, of course, should be a method which does not require the
server to know the password and does not disclose the password to the
user.  According to rfc2831 SASL/DIGEST-MD5 is such a mechanism, yet
Section 3.9 "Storing passwords" says:

   if this password file is compromised, then an attacker gains
   immediate access to documents on the server using this realm.

I don't see what 'files' means in LDAP context.  Does this mean that
if our system encrypts passwords and throws away the unencrypted ones,
we can't use SASL/DIGEST-MD5 since we must to know the plaintext
passwords and re-encrypt them if the password file is stolen?

If not - Section 3.9 says the stored passwords will be a hash of
username-value, realm-value, and passwd, and that the realm should
include the name of the host doing the authentication.  Will
'ldap.uio.no' do for host here, where that will be the DNS name of
_several_ hosts?

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 11 Sep 2003 22:36:44 +0200

I wrote:
> I don't see what 'files' means in LDAP context.

Oops, s/files/documents/.  That was from my private notes.

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 16 Sep 2003 21:10:01 +0100

>I don't see what 'files' means in LDAP context.
password storage.

>  Does this mean that
I assumed below that you meant hashing, not encrypting here. Encryption 
is reversible.

>passwords and re-encrypt them if the password file is stolen?
You either store hash of username-value, realm-value, and passwd or you 
store a cleartext password (or encrypted version of it).
If you use different hashing and store only hashes, you can't use 
DIGEST-MD5.

The phrase

means that if you store DIGEST-MD5 hashes and they are stolen, this allows the person who stole them to access your LDAP server. However, imagine that you've stored a hash username:realm1:password on a compromised server A.
If another LDAP server B has an account for the same user "username" with the same password "password", but different realm, the hash from the compromised server is not good on the LDAP server B.

>'ldap.uio.no' do for host here, where that will be the DNS name of
It will, but you risk that a compromise of a server from the list will 
mean compromise on all of them (assuming they share users).

Have I answered your questions?

Alexey

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 23 Sep 2003 15:14:52 +0200

>>I don't see what 'files' means in LDAP context.

Sorry, I meant 'documents on the server', not 'files'.  'files' was from
my private notes, with some misquoting...

That is, does this mean that one can authenticate as any in the password
file if the password file is compromised?

> I assumed below that you meant hashing, not encrypting here. Encryption 

Yes.

> Have I answered your questions?

Not quite, I must chew on this a bit...

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 25 Sep 2003 15:03:51 +0100

Hallvard B Furuseth wrote:

>>> Section 3.9 "Storing passwords" says: if this password file is 
>>> compromised, then an attacker gains immediate access to documents on 
>>> the server using this realm. I don't see what 'files' means in LDAP 
>>> context. 
>>
>> password storage. 
>
>
Yes, the same way as if you have all passwords in the clear. However,
1). these hashes are not good for other servers, even if the same user 
has an account and uses the same password. They are effectively "salted" 
with realm, which will be in most cases different;
2). changing realm used by the compromised server, should disallow 
access to anyone.

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

Alexey

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 25 Sep 2003 17:08:28 +0200

Alexey Melnikov writes:
>>>> the server using this realm.
>> (...)
>>

Thanks.

I hope to see something about this in the Security Considerations of the
Authmeth draft.  Though perhaps it should wait to after -07 is out.

-- 
Hallvard