A simple usecase being ignored
Mathias Laurenz Baumann
marenz at supradigital.org
Tue Aug 10 02:12:11 EDT 2010
After reading over my mail again, I saw some potential bad
phrased/explained points. Let me clarify here:
> 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.
Registering means the one-time process of creating an account on the
After that they can just "link" to their identities. For that they need to
auth using sasl.
> 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
> host-internal function.
What I mean here is, sasl calls the mechanisms setpasswd function and
provides structs with function-pointers for utility functions as well as
functions like sasl_setprop. I would create a copy of that structure and
change the provided function-pointer for sasl_setprop to a function in my
This is my first proposal for a change in libsasl:
> 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.
(just to make sure it doesn't get over-read)
> 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.
And this my second proposal:
> Again, the solution would be very simple: let the hostapplication
> provide some callbacks in libsasl so it can take care of
> 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