Re: SCRAM methods

[Simon Josefsson]

Simon Josefsson <address@hidden> writes:

> Jeremy Harris <address@hidden> writes:
>
>> Hi,
>>
>> On 25/12/2019 16:31, Jeremy Harris wrote:
>>> So, please consider these feature requests:
>>> 
>>> - library API returning a salted-password, given password and
>>>   optional salt, optional iteration-count
>>> - utility access to that API
>>> - library acceptance and use, server side, of a salted password.
>>
>> I have written the code for parts 3 and 1 of the above, and
>> tested with Exim.  These patches apply cumulatively onto
>> d5976869c4.
>>
>> The first patch makes the server-side SCRAM implementation behave like
>> the client-side, in that it looks for a salted-password property first,
>> then falling back to the existing use of a plaintext-password property.
>> The server application must still supply the salt and iteration-count.
>>
>> The second patch writes a salted-password property, server-side, if the
>> plaintext source and calculation procedure is followed; this permits an
>> application to extract the salted-password for storage.
>>
>> I've not touched the docs.
>
> Thank you -- I have added this on the 'scram-sha256' branch which is
> where all development happens right now.  I will improve the docs to
> match the new behaviour.

When writing the documentation for this, I realized we got this all
wrong.  Clients and servers should NOT store the salted password!  The
salted password is a password-equivalent that can be used to impersonate
a client or server.

Clients should store the ClientKey:

ClientKey       := HMAC(SaltedPassword, "Client Key")

This allows the client to perform the client-side authentication.  An
attacker who steals the ClientKey cannot impersonate a server.

Servers should store StoredKey and the ServerKey:

     StoredKey       := H(ClientKey)
     ServerKey       := HMAC(SaltedPassword, "Server Key")

These two allow the server to perform the server-side authentication.
An attacker who steals StoredKey or ServerKey cannot impersonate a
client.

In conclusion, the GSASL_SCRAM_SALTED_PASSWORD property should probably
not be used by Exim.  It should only be used if the client/server have
the password in PBKDF2 form through some other database, and wants to
use it for SCRAM-specific use.  There might exist real use-cases for
this, since stored PBKDF2 passwords are fairly common.  This defeats one
of the big advantage with SCRAM so shouldn't be recommended though.

I believe the right thing to do is to introduce new properties
GSASL_SCRAM_CLIENTKEY, GSASL_SCRAM_STOREDKEY and GSASL_SCRAM_SERVERKEY.

Back to the drawing board a bit...  I'll back out some of the changes
I've made on the scram-sha256 branch.

/Simon

signature.asc
Description: PGP signature