A simple usecase being ignored
Mathias Laurenz Baumann
marenz at supradigital.org
Tue Aug 10 02:03:02 EDT 2010
I plan to use sasl for a conferencing protocol. Users would register using
a simple registering mechanism using the protocol itself, before they link
themselves to their identities.
I don't want my server to ever know the plain-text password. So I mainly
want to use SCRAM and SRP.
The server itself takes care of storing the secrets (I define a secret as
something that proves that you know the password).
For this to work, a client would simply transmit the secret (not the plain
password- in the registering process so the server can add it
to its database. There are several problems in this scenario and the
library as it is now.
* To get the secret, the client has to call sasl_setpasswd with the
appropriate mechanisms enabled (at least SRP) which will use the auxprop
plugin(s) to set the secret.
** I can either write my own small auxprop plugin that does nothing more
than providing the secret to the host application or
** I call the mechanisms setpasswd function myself and change the
parameter for sasl_setprop (or something like this) to my own
Both solutions are ugly hacks in my opinion and yet the solution to this
would be very simple: A mechanism specific function that gets the password
and returns the secret. A third possibility exists:
** Write a auxprop plugin that does the registering process itself. I
don't like this solution, as it requires creating a connection and takes
away the control from the library user. But this would be the only one not
being an ugly hack.
* the server manages the storing itself, yet libsasl requires me to write
a auxprop plugin which would in turn just call/forward the calls back to
the server. Also an ugly hack. Again, the solution would be very simple:
let the hostapplication provide some callbacks in libsasl so it can take
care of fetching/storing.
On a side note:
I discovered, that only SRP and OTP use prop_set to store their
cmusaslsecret* using the auxprop plugin and that for example CRAM doesn't
provide a setpasswd function at all. I don't understand why? Doesn't CRAM
(and some others) use only a secret for authentication? How would the
cmusaslsecret for CRAM be created?
I was very surprised to discover that these very simple usecases are so
difficult to realize. I assumed this would be the normal usecase.
what do you think about my proposed changes/extensions to libsasl?
More information about the Cyrus-sasl