Re: on using GSASL_SCRAM_SALTED_PASSWORD

[Simon Josefsson]

Marco Maggi <address@hidden> writes:

> Ciao,
>
>   I  am  binding  GSASL  to   a  language;  I  am  not  into
> cryptography; I would like to  stay out of crypto algorithms
> implementation as much as I can.

That is wise.   What language are you targetting?

>   For the purpose of including examples in the documentation
> I  have written  a  pair  of mock  client  and server  using
> SCRAM-SHA-1 and  it seems to  me that they can  correctly do
> their   thing  with   the   client   setting  the   property
> GSASL_PASSWORD.

Great.

>   Questions:
>
> * I  am in  a  bit  of trouble  implementing  an example  of
>   setting the  property GSASL_SCRAM_SALTED_PASSWORD;  is the
>   client application supposed to:
>
>   1.  Retrieve the  property  GSASL_SCRAM_ITER  as a  string
>      holding a  number of iterations,  and convert it  to an
>      actual number "i".
>
>   2. Retrieve  the property GSASL_SCRAM_SALT as  a string in
>      base64 encoding, and decode  it obtaining the vector of
>      octets "salt".
>
>   3.  Take  the  password  in  clear  and  prepare  it  with
>      SASLprep, obtaining the vector of octets "str".
>
>   4. Compute the  function Hi(str, salt, i)  as explained in
>      RFC 5802, obtaining a vector of octets.
>
>   5. Convert  the vector  of octets  from point  4 to  a hex
>      string (it must result of length 40).
>
>   and  the  hex   string  is  the  value   of  the  property
>   GSASL_SCRAM_SALTED_PASSWORD?

Yes I believe this is correct.  Possibly your explanation could be added
to the manual, to explain this, since it is a bit complicated.

> * 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.  Then
anyone getting accessing to the disk will not get the real password, but
just a hashed version of it.

> * Being that, IIUC, GSASL  already implements internally the
>   transformation   from   clear   password   to   value   of
>   GSASL_SCRAM_SALTED_PASSWORD,  is it  possible to  just use
>   GSASL to compute the value of the property?

Not easily -- you can implement PBKDF2 yourself using gsasl_hmac_sha1.
What do you think about a new helper function (in lib/src/crypto.c) to
do this?

Thanks,
/Simon