After reading over my mail again, I saw some potential bad
phrased/explained points. Let me clarify here:
Greetings,
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
server.
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
host application
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
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?
Greetings,
--Marenz
