Re: SCRAM methods

[Jeremy Harris]

On 03/01/2020 14:40, Simon Josefsson wrote:
> 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")

... along with salt, itercnt?


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

Right.  I'll probably not implement that PBKDF2 support unless it
gets asked for, in favour of only having the more-secure offering.

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

Sounds reasonable.


I agree a server changing itercnt or salt will have to be assumed
uncommon.  I think doing it server-side would require the plaintext
password, and recovery from it on a client would also.  Since those
require user interaction I don't see a need for any extra handling
in the library or in Exim (I guess other client apps might want to
either prompt the user or provide for a first-time password, held
in clear only until the initial use permits the extraction of ClientKey
from the library).

I do hope that distros package the utility up with the library.
I don't find a "gsasl" command on this Fedora system...

-- 
Cheers,
  Jeremy