Re: on using GSASL_SCRAM_SALTED_PASSWORD

[Marco Maggi]

Simon Josefsson wrote:
>> * Given  that to compute  such property value I  need the
>> password in clear, in which scenario a client application
>> should   use   GSASL_SCRAM_SALTED_PASSWORD  rather   than
>> GSASL_PASSWORD?

> Typically  when the  client is  storing the  credential on
> persistant storage  for re-use at  a later time.   What is
> stored  on the  disk  should then  ideally  be the  salted
> password instead of the plain password.

But IIUC this is not possible; the function Hi(str, salt, i)
defined in RFC  5802, which the client  must compute, starts
with:

  HMAC(str, salt + INT(1))

where the password  "str" is needed in clear  and the "salt"
is  generated  by the  server;  subsequent  steps also  need
"str".   So  the  client  cannot  precompute  the  value  of
GSASL_SCRAM_SALTED_PASSWORD,  it needs  a database  of clear
passwords  (or entries  that can  be decoded  to clear  when
needed).

  The  server  could  have  access only  to  a  database  of
precomputed values, if the salt and the number of iterations
is decided  once and for all,  but under GSASL I  do not see
the      server      callback     being      called      for
GSASL_SCRAM_SALTED_PASSWORD;   also   the   RFC   explicitly
suggests to generate random salts (and I understand it means
"new"  salts).  So  the  server needs  a  database of  clear
passwords, too.
-- 
Marco Maggi