Re: SCRAM methods

[Simon Josefsson]

Jeremy Harris <address@hidden> writes:

> Hi,
>
> I'm looking at expanding the usage that Exim (an SMTP MTA) can
> make of libgsasl.  There has been server-only coverage for a while;
> I'm adding client-side and looking specifically at the SCRAM family
> of methods.
>
> I see from the git that SCRAM-SHA-256 is on the way, which is very
> pleasing.

Hi Jeremy!  Yay, your work is very timely since I will be spending some
time updating gsasl now.

> However - there seems to be no way to supply, on the server side,
> the password in non-cleartext (at least, per the docs.  I've not
> tried writing a GSASL_SCRAM_SALTED_PASSWORD property yet,
> mainly because of a second issue [below]).

Indeed you are right -- the gsasl scram server does not support
GSASL_SCRAM_SALTED_PASSWORD.

>  This lack seems at variance with one of the major advantages
> of SCRAM noted in RFC 5802:
>
>    o  The authentication information stored in the authentication
>       database is not sufficient by itself to impersonate the client.
>       The information is salted to prevent a pre-stored dictionary
>       attack if the database is stolen.
>
> - at least as applied to the server.

You are right.  Having this would be a great feature, to allow servers
to not store password-equivalents.

I'm going to work on this together with SCRAM-SHA256.

> The library does support the client only storing a salted version of
> the password, though it isn't entirely clear how that works in
> combination with the server possibly using a different salt (as
> permitted by the protocol definition, if impractical vs. storage of
> salted passwords) or different iteration-count (also permitted by the
> protocol, and without any practical problems I can see).

The server supplies the salt and iteration counts.  If they differ from
before, the client must re-compute the "prepared" password using the
real password.

> The second issue is that there is no way to extract a
> salted-password from the library.  Without coding a full duplicate
> implementation, it seems difficult for an application to get
> one to store in the first place - for later use either on a
> client or on a server.

Yes -- there should be an API for this in gsasl.

> So, please consider these feature requests:
>
> - library API returning a salted-password, given password and
>   optional salt, optional iteration-count

I agree.

For a server, the API should return a salted-password, fresh salt and
recommended iteration count.  For a client, the API should return a
salted password for a given salt and iteration count.  Probably it
should be the same API call.

> - utility access to that API

Right.  The 'gsasl' tool could be expanded with this functionality.

> - library acceptance and use, server side, of a salted password.

I agree.

/Simon

signature.asc
Description: PGP signature